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.3 required=5.0 tests=BAYES_00,FREEMAIL_FROM, REPLYTO_WITHOUT_TO_CC autolearn=no 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 05:04:13 PST Message-ID: <40487ac1_1@127.0.0.1> From: pburnand0-news@yahoo.com Subject: Re: Little Endian -> Big Endian (Ada95 / GNAT), Whats with floating point types? Newsgroups: comp.lang.ada Reply-To: pburnand0-news@yahoo.com Date: Fri, 05 Mar 2004 14:48:47 +0100 References: <4046b474_1@127.0.0.1> User-Agent: KNode/0.7.1 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7Bit X-Authenticated-User: $$laz_wrsc X-Comments: This message was posted through Newsfeed.com X-Comments2: IMPORTANT: Newsfeeds.com does not condone, nor support, spam or any illegal or copyrighted postings. X-Comments3: IMPORTANT: Under NO circumstances will postings containing illegal or copyrighted material through this service be tolerated!! X-Report: Please report illegal or inappropriate use to You may also use our online abuse reporting from: http://www.newsfeed.com/abuseform.htm X-Abuse-Info: Please be sure to forward a copy of ALL headers, INCLUDING the body (DO NOT SEND ATTACHMENTS) Organization: Newsfeed.com http://www.newsfeed.com 100,000+ UNCENSORED Newsgroups. Path: archiver1.google.com!news2.google.com!newsfeed2.dallas1.level3.net!news.level3.com!zeus.visi.com!news-out.visi.com!petbe.visi.com!news.octanews.net!feed5.newsreader.com!newsreader.com!news-out2.nntp.be!local!corp-news!not-for-mail Xref: archiver1.google.com comp.lang.ada:6079 Date: 2004-03-05T14:48:47+01:00 List-Id: 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... 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... > 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. 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... > 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... Doing exactly the same calculation on different computer systems can even give largely different results. Let's take an example: You need to calculate 1.0000000009789847 ** 1.000000087437987e+18 If you have a large enough precision, you should find a quite large number. If you use a low precision FPU or format, the very same calculation becomes 1.000000e+00 ** 1.000000e+18 which gives 1.0e+00...