* Re: Floating point problems in GNAT @ 1997-02-12 0:00 Wolfgang Lohmann [not found] ` <E5KKo6.CKH@thomsoft.com> 0 siblings, 1 reply; 4+ messages in thread From: Wolfgang Lohmann @ 1997-02-12 0:00 UTC (permalink / raw) [was: Comparison of Values from My_Float is digit 8; for similar calculations with same values in different order led to unequality.] To give my salt to the soup: To check two or more Floatvalues on equality one normally introduces a constant, let's say Epsilon : My_Float := 0.00000001; which represents the minimal difference of your Floattypevalues at the last significant position. If the difference of the two paths is smaller than Epilon the paths are equal with respect to (in this case) 8 required significant digits. Thus 0.12345678_0999999999 and 0.12345678_1000000000 are equal, which is what I would expect (or am I wrong ?). The use of My_Float'First as Epsilon led to wrong results. Regards, Wolfgang N.B.: I learnt this lesson from "while not ( A_Float = B_Float) ..." ^ permalink raw reply [flat|nested] 4+ messages in thread
[parent not found: <E5KKo6.CKH@thomsoft.com>]
[parent not found: <EACHUS.97Feb14115527@spectre.mitre.org>]
* Re: Floating point problems in GNAT [not found] ` <EACHUS.97Feb14115527@spectre.mitre.org> @ 1997-02-16 0:00 ` Keith Thompson 1997-02-16 0:00 ` Robert Dewar 0 siblings, 1 reply; 4+ messages in thread From: Keith Thompson @ 1997-02-16 0:00 UTC (permalink / raw) In <EACHUS.97Feb14115527@spectre.mitre.org> 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 <http://www.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. ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Floating point problems in GNAT 1997-02-16 0:00 ` Keith Thompson @ 1997-02-16 0:00 ` Robert Dewar 0 siblings, 0 replies; 4+ messages in thread From: Robert Dewar @ 1997-02-16 0:00 UTC (permalink / raw) Keith said <<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.>> This seems a poor example, since it is no different from the situation in integer arithmetic, where 1/3 also is "inexact". ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Floating point problems in GNAT [not found] ` <E5KKo6.CKH@thomsoft.com> [not found] ` <EACHUS.97Feb14115527@spectre.mitre.org> @ 1997-02-19 0:00 ` Robert I. Eachus 1 sibling, 0 replies; 4+ messages in thread From: Robert I. Eachus @ 1997-02-19 0:00 UTC (permalink / raw) In article <E5oBMH.6rA@thomsoft.com> kst@aonix.com (Keith Thompson) writes: > 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. Looks like an implicit conversion to me, and I said that some conversions are not exact. ;-) Note that in this problem, the square root operation in the Distance function by its nature is inexact for most values, since the exact value is irrational. However for the fixed point case, all we care is that Distance return the same result each time it is called with the same points as arguments. But my real (ouch!) point was that the addition and comparison operations for fixed point types are exact. In this case, that means that the order of additions in floating point is significant and will result in different answers, while in fixed point the order of additions is immaterial. (We know that all values are positive, so intermediate overflows are not an issue.) I'm probably beating a very dead horse here, but my guess is that 90% of the programmers out there not only don't understand fixed point, but don't know when the distinction between fixed and floating point is important. -- Robert I. Eachus with Standard_Disclaimer; use Standard_Disclaimer; function Message (Text: in Clever_Ideas) return Better_Ideas is... ^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~1997-02-19 0:00 UTC | newest] Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 1997-02-12 0:00 Floating point problems in GNAT Wolfgang Lohmann [not found] ` <E5KKo6.CKH@thomsoft.com> [not found] ` <EACHUS.97Feb14115527@spectre.mitre.org> 1997-02-16 0:00 ` Keith Thompson 1997-02-16 0:00 ` Robert Dewar 1997-02-19 0:00 ` Robert I. Eachus
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox