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-28 10:23:33 PST Path: archiver1.google.com!news2.google.com!fu-berlin.de!uni-berlin.de!82-43-33-75.cable.ubr01.croy.blueyonder.co.UK!not-for-mail From: Nick Roberts Newsgroups: comp.lang.ada Subject: Re: Why no 'Floor for fixed point types Date: Tue, 28 Oct 2003 18:23:31 +0000 Message-ID: References: <3F99FBE1.1030601@comcast.net> <3F9AFB67.5080401@comcast.net> <3F9DC3D6.4010106@comcast.net> NNTP-Posting-Host: 82-43-33-75.cable.ubr01.croy.blueyonder.co.uk (82.43.33.75) Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Trace: news.uni-berlin.de 1067365412 36941716 82.43.33.75 (16 [25716]) User-Agent: Mozilla/5.0 (Windows; U; Win95; en-US; rv:1.5) Gecko/20031013 Thunderbird/0.3 X-Accept-Language: en-us, en In-Reply-To: <3F9DC3D6.4010106@comcast.net> Xref: archiver1.google.com comp.lang.ada:1781 Date: 2003-10-28T18:23:31+00:00 List-Id: 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