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,4ac6504560f5ef27 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2004-03-05 09:48:33 PST Path: archiver1.google.com!news2.google.com!newsfeed2.dallas1.level3.net!news.level3.com!zeus.visi.com!news-out.visi.com!priapus.visi.com!orange.octanews.net!news.octanews.net!green.octanews.net!news-out.octanews.net!news.glorb.com!wn14feed!worldnet.att.net!207.35.177.252!nf3.bellglobal.com!nf1.bellglobal.com!nf2.bellglobal.com!news20.bellglobal.com.POSTED!not-for-mail From: "Warren W. Gay VE3WWG" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 Newsgroups: comp.lang.ada Subject: Re: Little Endian -> Big Endian (Ada95 / GNAT), Whats with floating point types? References: <4046b474_1@127.0.0.1> <40487ac1_1@127.0.0.1> In-Reply-To: <40487ac1_1@127.0.0.1> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: Date: Fri, 05 Mar 2004 12:34:30 -0500 NNTP-Posting-Host: 198.96.223.163 X-Complaints-To: abuse@sympatico.ca X-Trace: news20.bellglobal.com 1078508009 198.96.223.163 (Fri, 05 Mar 2004 12:33:29 EST) NNTP-Posting-Date: Fri, 05 Mar 2004 12:33:29 EST Organization: Bell Sympatico Xref: archiver1.google.com comp.lang.ada:6088 Date: 2004-03-05T12:34:30-05:00 List-Id: pburnand0-news@yahoo.com wrote: > Warren W. Gay VE3WWG wrote: >>Marius Amado Alves wrote: >>>>... Also, there is a small performance penalty paid for >>>>shuffling bits around to achieve platform independence. >>>But surely less than converting to an ASCII image and back. (I suspect >>>that, contrary to what has been indicated, the significant performance >>>loss in the ASCII solution is of time, not space.) >>> >>>But the ASCII solution is a nice, safe one if you don't have the time or >>>the will or the possibility to learn to use or just to use the >>>compiler's. Remember Ada has the wonderful 'Image and 'Value attributes >>>which take care of the conversion for you. >> >>I'm no floating point numeric expert, but by converting to >>a standard, say IEEE floating point format, you can still >>represent a machine dependant number with repeating decimal >>places in a IEEE floating point format (I assume). Mind >>you, this depends heavily upon the differences between the >>two formats. > > Even if there is a standard format, using binary format, there is always the > problem of the byteorder and such... Of course, but that was not my point. > Using ASCII is cool, because a number is always read from left to right... > So you can write a floating point number in Ada on Linux and read it in a C > program on Windows to store it in a double or a float. All combinations > are possible... ASCII is also more expensive in time and space. Not much of a consequence when you transmitting a few numbers, but is much different if you are transmitting millions of them. It makes to plan for the worst case in some of these situations. >>By converting to ASCII, you lose that, unless you encode >>the fact that the last digit repeats, in some way (like >>the number "1.33333*", where * might represent "repeat"). > > There are always losses. Agreed. > If you want to keep the number as exact as > possible, you should use your Ada packages in a way to print the maximal > number of decimals. You should always be able to control the format of the > output. > > So there should be no numer so short as "1.33333", even with the lowest > precision format... I think you missed my point (repeating decimals). >>If they don't do that, then the number has been rounded, >>and thus does not quite represent the original value any >>more ;-) (at a minimum, it is less faithful than it >>could be). > > The floating point numbers are always rounded even in an FPU. No software, > no hardware can handle an infinite number of digits... Of course. But my point was that some hardware does keep a bit (IIRC), that indicates that this is a repeating digit (binary/decimal). The point of this is to reduce error. > Doing exactly the same calculation on different computer systems can even > give largely different results. No kidding. -- Warren W. Gay VE3WWG http://ve3wwg.tk