From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7359 invoked from network); 31 Oct 2002 18:54:47 -0000 Received: from sunsite.dk (130.225.247.90) by ns1.primenet.com.au with SMTP; 31 Oct 2002 18:54:47 -0000 Received: (qmail 5790 invoked by alias); 31 Oct 2002 18:54:17 -0000 Mailing-List: contact zsh-workers-help@sunsite.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 17888 Received: (qmail 5741 invoked from network); 31 Oct 2002 18:54:03 -0000 Date: Thu, 31 Oct 2002 10:53:01 -0800 From: Wayne Davison To: Zsh hackers list Subject: Re: PATCH: my "SECONDS can be floating point" tweaks Message-ID: <20021031185301.GD8814@scuzzy.blorf.net> References: <22634.1035831352@csr.com> <20021030211750.GA6296@scuzzy.blorf.net> <1021031050931.ZM5514@candle.brasslantern.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1021031050931.ZM5514@candle.brasslantern.com> User-Agent: Mutt/1.3.28i On Thu, Oct 31, 2002 at 05:09:31AM +0000, Bart Schaefer wrote: > Is converting to float and then back to integer (or the other way round > for the setfn) really going to give the same results as a computation > directly on only shtimer.tv_sec? Not the same but more accurate. For example: if the script starts in second "5" (long ago) .9 seconds into that second and the script references $SECONDS .2 seconds later, the old version would report that we've been running for 1 second. The new version would report 0 seconds have elapsed until we get .9 seconds into second "6". So, the new method causes the time to be calculated more accurately and then the decimal points just get truncated (as you surmised: the value is not rounded). > I don't follow what this means from the point of view of the _caller_ > of a function in which SECONDS is local. What it means is that the parent function's variable remains unaffected by any child's local parameter. Before this change the parent's value could get more and more inaccurate each time a local value was used and then added into the parent's value. I.e., the old method was to save off the elapsed time (say "8" seconds), run the local function, at which point we add in the elapsed time of the child function (say "1") to our value and then reset the SECONDS variable in the parent (setting it to "9"). If we were near a second boundary in either the saving of the "8" or the adding of the "1", the real value could easily be 1 second off (i.e. "10"), but that should be a fairly rare error (I would imagine). Switching the parent into float for better accuracy would (I believe) cause a steady stream of micro-seconds errors from each child to accumulate at a very slow rate (since the time used in the code that saves the parent value and adds the child value contains untimed sections). The new code just remembers the real start time of the parent's variable and restores it, so the value remains unchanged no matter how many calls are made. ..wayne..