Re: Floating point problems in GNAT

Re: Floating point problems in GNAT

[Wolfgang Lohmann]

[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) ..."

Re: Floating point problems in GNAT

[Keith Thompson]

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.

Re: Floating point problems in GNAT

[Robert Dewar]

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".

Re: Floating point problems in GNAT

[Robert I. Eachus]

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...