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.9 required=5.0 tests=BAYES_00,FREEMAIL_FROM, FREEMAIL_REPLY autolearn=no 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-27 17:19:56 PST Path: archiver1.google.com!news2.google.com!news.maxwell.syr.edu!newsfeed.mathworks.com!wn13feed!worldnet.att.net!204.127.198.203!attbi_feed3!attbi_feed4!attbi.com!attbi_s53.POSTED!not-for-mail Message-ID: <3F9DC3D6.4010106@comcast.net> From: "Robert I. Eachus" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 Newsgroups: comp.lang.ada Subject: Re: Why no 'Floor for fixed point types References: <3F99FBE1.1030601@comcast.net> <3F9AFB67.5080401@comcast.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit NNTP-Posting-Host: 24.34.139.183 X-Complaints-To: abuse@comcast.net X-Trace: attbi_s53 1067303995 24.34.139.183 (Tue, 28 Oct 2003 01:19:55 GMT) NNTP-Posting-Date: Tue, 28 Oct 2003 01:19:55 GMT Organization: Comcast Online Date: Tue, 28 Oct 2003 01:19:55 GMT Xref: archiver1.google.com comp.lang.ada:1755 Date: 2003-10-28T01:19:55+00:00 List-Id: Randy Brukardt wrote: > "Robert I. Eachus" wrote in message > news:3F9AFB67.5080401@comcast.net... > >>But you didn't pay attention above. The compiler allows you to think >>about fixed-point types as if they are real (non-integer) values. But >>they are not implemented that way. Any compiler that uses >>floating-point arithmetic to do fixed-point computations has a lot of >>bugs in it. They just havent been found yet. (And I think it was ACVC >>1.4 that added a lot of tests which found such bugs.) > > As usual with blanket statements, this is wrong. Janus/Ada in fact does use > floating-point arithmetic to implement fixed point in some cases (especially > the mixed multiply). We did the error analysis on these operations, and they > are fine - they'll get the right answer in all cases that Ada 95 requires > that. (There are some cases where no technique will get the "right" answer > as defined in Ada 83, and those of course we might get wrong for some bit > patterns. Many Ada 83 compilers simply avoided the issue by restricting > 'Small to powers of two, which of course is trivial to get right. And rather > restrictive.) Since, in a generic, you don't know the 'Smalls involved, and > you don't know the magatude of the values, there isn't much else to do > except use the highest precision math that you have available. As with > everything, it depends on how you use it. Actually, I think you are agreeing with me. 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. 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). 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. 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.) 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.) -- Robert I. Eachus "Quality is the Buddha. Quality is scientific reality. Quality is the goal of Art. It remains to work these concepts into a practical, down-to-earth context, and for this there is nothing more practical or down-to-earth than what I have been talking about all along...the repair of an old motorcycle." -- from Zen and the Art of Motorcycle Maintenance by Robert Pirsig