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.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,6a77269912f77a70 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2003-10-29 11:28:11 PST Path: archiver1.google.com!news2.google.com!news.maxwell.syr.edu!sn-xit-03!sn-xit-01!sn-post-02!sn-post-01!supernews.com!corp.supernews.com!not-for-mail From: "Randy Brukardt" Newsgroups: comp.lang.ada Subject: Re: Why no 'Floor for fixed point types Date: Wed, 29 Oct 2003 13:26:30 -0600 Organization: Posted via Supernews, http://www.supernews.com Message-ID: References: <3F99FBE1.1030601@comcast.net> <3F9AFB67.5080401@comcast.net> <3F9DC3D6.4010106@comcast.net> X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 X-Complaints-To: abuse@supernews.com Xref: archiver1.google.com comp.lang.ada:1818 Date: 2003-10-29T13:26:30-06:00 List-Id: "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. :-) This is wrong (which was my original point). Ada requires such results to be members of the "close result set", which is implementation-defined. Thus, the only way for there to be actual "errors" or "bugs" in these result is if we've defined that set incorrectly (implementation-defined stuff is supposed to be documented). Of course, if it is proved that we've done that wrong, it's highly unlikely that we'd change the compiler; just the documentation. So in practice it means that such results have whatever accuracy the compiler writer can easily support. > > 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. Read G.2.3 to see what the RM says about the accuracy of fixed point. In particular, read about the 'perfect result set' and the 'close result set'. If you care about accuracy, you need to avoid operations which only require a result in the 'close result set', because those are cases that the compiler is allowed to be inaccurate. Randy.