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.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,486bed9a72d373b X-Google-Attributes: gid103376,public From: kst@aonix.com (Keith Thompson) Subject: Re: Floating point problems in GNAT Date: 1997/02/16 Message-ID: #1/1 X-Deja-AN: 219090715 Sender: news@thomsoft.com (USENET News Admin @flash) X-Nntp-Posting-Host: pulsar References: <5dt3n1$jnf@taiwan.informatik.uni-rostock.de> Organization: Aonix, San Diego, CA, USA Newsgroups: comp.lang.ada Originator: kst@pulsar Date: 1997-02-16T00:00:00+00:00 List-Id: In eachus@spectre.mitre.org (Robert I. Eachus) writes: > Correct in general, but in Ada there all fixed-point operations > other than division by an Integer and some type conversions are exact. > (Of course the Ada rules require implicit or explicit conversion the > results of multiplying or dividing two fixed-point values, now you > know why.) So catastrophic loss of precision can occur, but most > fixed-point code can be written to avoid loss of precision entirely. Yes, that's true. Note, however, that in Ada 95 (unlike Ada 83) the following is legal: A : Duration := 1.0; B : Duration := 3.0; C : Duration := A / B; The division operator yields a result of type universal_fixed; the implicit conversion back to type Duration causes a loss of precision. As far as the programmer is concerned, this looks like an inexact division operation on type Duration. Real arithmetic is tricky. -- Keith Thompson (The_Other_Keith) kst@aonix.com <*> TeleSo^H^H^H^H^H^H Alsy^H^H^H^H Thomson Softw^H^H^H^H^H^H^H^H^H^H^H^H^H Aonix 10251 Vista Sorrento Parkway, Suite 300, San Diego, CA, USA, 92121-2706 Antimatter is not a condiment.