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=-1.1 required=5.0 tests=BAYES_00, PP_MIME_FAKE_ASCII_TEXT autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII X-Google-Thread: 103376,6a77269912f77a70 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2003-10-28 10:34:36 PST Path: archiver1.google.com!news2.google.com!news.maxwell.syr.edu!in.100proofnews.com!in.100proofnews.com!cycny01.gnilink.net!cyclone1.gnilink.net!spamkiller2.gnilink.net!nwrdny02.gnilink.net.POSTED!53ab2750!not-for-mail From: "Stephane Richard" Newsgroups: comp.lang.ada References: <3F99FBE1.1030601@comcast.net> <3F9AFB67.5080401@comcast.net> <3F9DC3D6.4010106@comcast.net> Subject: Re: Why no 'Floor for fixed point types X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Message-ID: <0Fynb.33992$1C5.19954@nwrdny02.gnilink.net> Date: Tue, 28 Oct 2003 18:34:36 GMT NNTP-Posting-Host: 129.44.78.169 X-Complaints-To: abuse@verizon.net X-Trace: nwrdny02.gnilink.net 1067366076 129.44.78.169 (Tue, 28 Oct 2003 13:34:36 EST) NNTP-Posting-Date: Tue, 28 Oct 2003 13:34:36 EST Xref: archiver1.google.com comp.lang.ada:1783 Date: 2003-10-28T18:34:36+00:00 List-Id: In the worlds of our common savior <- .oO( Yeah Right!!! ) Bill Gates...hehehe....if nobody cares, it's a bug...if everyone cares, it's a feature..;-) -- St�phane Richard "Ada World" Webmaster http://www.adaworld.com "Nick Roberts" wrote in message news:bnmc74$137bsk$1@ID-25716.news.uni-berlin.de... > Robert I. Eachus wrote: > > > ... Trying to test even a small > > subset of all possible reasonable values of 'Small and fixed-point > > numbers just isn't reasonably possible without trillions of machines > > crunching for millions of years. So your compiler probably has > > millions of errors in the low order bit that are just not practical to > > find, and of no real interest to anyone anyway. > > So possibly a question we should ask is "If nobody cares, does it count as > an error (or bug)?" I admit, there might be a few Intel customers who'd > like to know the answer to that one. :-) > > > From experience with > > fixed-point, the tough cases are of the form A := Fixed(B*C); where B > > and C are of two other types than Fixed, and there is no easy > > representation of Fixed'Small/(B_type'Small * C_type'Small). > > What do you mean when you say these are tough cases? The RM95 essentially > says that the result is either of the representable values (of the type > Fixed here) which bound the precise result. > > > In practice those cases are of little or no interest to anyone. If your > > compiler correctly implements A := A * I; where I is an Integer, or A := > > B + C; where all three are of the same fixed-point type, then I and most > > other fixed-point users won't care about those painful cases. Other > > than, of course, to note that they exist so that we can avoid them. > > But why are the cases you refer to painful? Do they really need to be avoided? > > I can certainly see that if a calculation causes a missile to hit someone's > house (instead of the next door embassy), it might be quite painful for the > occupants of the house. Are you saying that these cases are capable of > being sources of nasty accidents, or are you saying that they are merely an > academic curiosity, of no possible practical consequence? (And I realise > this may be a slightly unfair question.) > > > If you do use the three type multiplication operator, you should check > > whether it is an easy or hard case, and avoid the hard cases. (Any > > conversion where the target type is the same as one of the multiplicand > > types counts as easy, since it can be done with a single division.) > > Would you please provide an example, to illustrate this point. > > > I'm not trying to scare anyone here. In fact one of the differences > > between Ada 83 and Ada 95 is that the error bounds on the hard cases > > were changed to make them easier to implement. The hard cases do come > > up, and for example, one of the harder parts of the Euro conversion was > > to specify rules and error bounds for some of these three type > > conversions. (Say from Marks to Kronar, using today's market rates for > > Marks to Euros and Euros to Kronar.) > > I seem to dimly recall you mentioning this before, Robert. Was it in > comp.lang.ada? I would like to review it on Google, if possible. > > -- > Nick Roberts >