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,7a2d45f282a1da1c X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2003-08-21 06:55:34 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!bloom-beacon.mit.edu!cambridge1-snf1.gtei.net!news.gtei.net!bos-service1.ext.raytheon.com!dfw-service2.ext.raytheon.com.POSTED!not-for-mail Message-ID: <3F44CF31.570ADCFA@raytheon.com> From: Mark Johnson X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 Newsgroups: comp.lang.ada Subject: Re: float with 24-bit resolution References: <3F3CCB0F.543478AF@adrianhoe.nospam.com.my> <3f40a43e@baen1673807.greenlnk.net> <3F43D1AB.10205@attbi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Thu, 21 Aug 2003 08:54:57 -0500 NNTP-Posting-Host: 192.27.48.39 X-Complaints-To: news@ext.ray.com X-Trace: dfw-service2.ext.raytheon.com 1061474133 192.27.48.39 (Thu, 21 Aug 2003 08:55:33 CDT) NNTP-Posting-Date: Thu, 21 Aug 2003 08:55:33 CDT Organization: Raytheon Company Xref: archiver1.google.com comp.lang.ada:41762 Date: 2003-08-21T08:54:57-05:00 List-Id: Ludovic Brenta wrote: > > [snip - use of decimal fixed point types] > > More important than being clearer, decimal types avoid some rounding > errors that only occur in binary representations. Some decimal > numbers do not have a finite representation in base 2. For example, > the number 0.42 (in base 10) becomes 0.01101011100001010001... in base > 2. This is one number that would require an infinite number of bits > to represent exactly, so any calculations made with it would involve > some rounding and loss of precision. The financial sector is one > particular industry where calculations must be absolutely exact to > some number of decimal, not binary, places. It is common, there, to > use packed-decimal representations where 4 bits correspond to exactly > 1 decimal place. In packed decimal, 0.42 would become 0.01000010, > requiring a finite number of bits. Actually, if you look at it carefully, binary can be an acceptable alternative - but you must use it in a different manner. For example, representing a number with two decimal digits of precision as an integer can be done where 042 (a value in memory / register) is interpreted as 0.42 in calculations and for display to the user. We generated data of that type (ages ago) on a machine that had no packed decimal types (nor floating point). That machine then sent the data to a "display computer" where a software divide by 10 routine (no hardware divide) was used to generate the values to display to the user. That method did a few more calculations to conserve scarce I/O resources. For machines where packed decimal is supported, what you say is true, but it is not the only alternative. This other way of looking at fixed types in general is simply to treat like integers - with a specified value as the LSB (not one). In the example above, the LSB is 0.01. The compiler still has to work out all the arithmetic operations and side effects, but it is feasible. --Mark