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 07:35:47 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!news.uchicago.edu!yellow.newsread.com!netaxs.com!newsread.com!newsfeed00.sul.t-online.de!t-online.de!skynet.be!skynet.be!skynet.be!skynet.be!louie!tlk!not-for-mail Sender: lbrenta@lbrenta 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> <3F44CF31.570ADCFA@raytheon.com> From: Ludovic Brenta Date: 21 Aug 2003 16:35:17 +0200 Message-ID: User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Organization: -= Belgacom Usenet Service =- NNTP-Posting-Host: 80.200.133.180 X-Trace: 1061476536 reader1.news.skynet.be 287 80.200.133.180:45372 X-Complaints-To: usenet-abuse@skynet.be Xref: archiver1.google.com comp.lang.ada:41763 Date: 2003-08-21T16:35:17+02:00 List-Id: Mark Johnson writes: > 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. What you describe is a second-best solution, and by your own accord you only used it because the target hardware did not support packed-decimal representations. Your divide-by-10 routine was the weak point; 10 happens not to be a power of two, and therefore any division of a binary number by 10 is bound to introduce rounding and imprecision. You may minimise the impact of that by doing the division as late as possible, e.g. for display purposes; this is probably what made the solution acceptable to you. However, if your program must write to a text file that serves as input to another program (and then another, etc.), then the loss of precision quickly becomes unacceptable. Well, all of this is off-topic; here's a nice way to come back to Ada: ARM B.4(13), package Interfaces.COBOL: type Decimal_Element is mod implementation-defined; type Packed_Decimal is array (Positive range <>) of Decimal_Element; pragma Pack(Packed_Decimal); :) -- Ludovic Brenta.