From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=0.7 required=5.0 tests=BAYES_00,MSGID_RANDY autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,f8311a3a7edd715 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2000-12-12 15:10:12 PST Path: supernews.google.com!sn-xit-02!supernews.com!newsfeed.mesh.ad.jp!portc01.blue.aol.com!news.maxwell.syr.edu!nntp2.deja.com!nnrp1.deja.com!not-for-mail From: Mike Silva Newsgroups: comp.lang.ada Subject: Re: Using "delay until" in real-time Date: Tue, 12 Dec 2000 23:02:54 GMT Organization: Deja.com Message-ID: <916aqq$9a7$1@nnrp1.deja.com> References: <915jl7$jt5$1@nnrp1.deja.com> <915p5n$p2j$1@nnrp1.deja.com> <915vv7$vfo$1@nnrp1.deja.com> NNTP-Posting-Host: 206.169.137.33 X-Article-Creation-Date: Tue Dec 12 23:02:54 2000 GMT X-Http-User-Agent: Mozilla/4.0 (compatible; MSIE 5.0; Windows 98; DigExt) X-Http-Proxy: 1.1 x52.deja.com:80 (Squid/1.1.22) for client 206.169.137.33 X-MyDeja-Info: XMYDJUIDmjsilva Xref: supernews.google.com comp.lang.ada:3022 Date: 2000-12-12T23:02:54+00:00 List-Id: In article <915vv7$vfo$1@nnrp1.deja.com>, Ted Dennison wrote: > In article <915p5n$p2j$1@nnrp1.deja.com>, > Mike Silva wrote: > > It's Son of Patriot bug... > > That's similar to what I called it. :-) > > > I'm as far from an expert as you can get, but what if you defined your > > Iteration in terms of Tick (4*Tick in your case)? Seems like that > > should provide an exact representation (why do I feel like that > > comment will get me nailed?). Otherwise, keep your own Iteration > > count in a scalar and add it (first converted to a Time_Span) to a > > Start_time for each delay until. > > I'm still feeling too dumb for not seeing this before to "nail" anyone > about it. Since Iteration_Hz in my old example was 4*tick, it sounds > like you are saying something like: > > task Executive is > Iteration_Count : Natural := 0; > Start_Time : Ada.Real_Time.Time := Ada.Real_Time.Clock; > begin > loop > -- do work > Iteration_Count := Iteration_Count + 1; > delay until Start_Time + (Iteration_Count * Iteration_Hz); > end loop; > end Executive; > > I see a couple of problems with this. > o This would only work for Natural'last iterations. That could be > accounted for though. Yep. You could, e.g. add 1.0 to Start_time and zero Iteration_count every 60 iterations. > o Iteration_Count * Iteration_Hz is no different mathematicly from > adding Iteration_Hz to Start_Time Iteration_Count times, which is what I > was doing. You'd still get the same compounding round-off error. I don't think so. Adding an imprecise float value N times will give a cumulative error that adding a scalar won't give. The final I/N division (really should be (I+epsilon)/N) won't have a cumulative error as long as you don't run out of bits to do the math. Still, I think it's better to try and represent your iteration in units of Ada.Real_Time.Tick. Then you are never dividing, only adding a scalar. If Ada.Real_Time.Tick can exactly represent your system tick of 1/240 sec. then you should never have an error. Then the question becomes whether Tick is an exact representation of the system tick time (seems like it would have to be!). > > > It's a very interesting question, and if I'm wrong I look forward to > > learning the right answer. > > Very. I had a lot of enthusiasticly offered ideas here at work when I > asked about it yesterday. Mike Sent via Deja.com http://www.deja.com/