From: nmm1 on
In article <1jmjjde.14qbtbo1ptpprwN%nospam(a)see.signature>,
Richard Maine <nospam(a)see.signature> wrote:
>
>Many people (myself included) do deprecate floating point equality tests
>for the reason that Philip mentioned. Depending on exact results from
>any floating point operation is risky except in special cases where you
>can be sure that no rounding would have been involved on any practical
>system. Rounding is fundamental to floating point. I recommend against
>using floating point at all until you have at least a basic appreciation
>of the implications of rounding. Yes, that means I think one needs to
>get a basic appreciation of the implications of rounding very early in
>learning Fortran. It doesn't need to be very sophisticated - just
>knowing that anything involving floating point can be inexact is
>sufficient for a start.

While that is all true, many other people (myself included) do NOT
deprecate floating-point equality tests, any more than relying on
ordering tests giving the 'right' order. I completely agree about
the need to understand rounding, and teach the viewpoint that
floating-point (whether by hand or on a computer) is an INEXACT
arithmetic. Yes, I am old-fashioned, there :-)

Unfortunately, IEEE 754 has made this area significantly trickier,
by introducing denormalised numbers, which have different semantics
in the area of comparisons. Note that I am NOT saying that they
are worse than hard underflow - just that they are different - so
programmers now need to understand both models.


Regards,
Nick Maclaren.
From: Dr Ivan D. Reid on
On Sun, 1 Aug 2010 10:25:33 -0700 (PDT), analyst41(a)hotmail.com
<analyst41(a)hotmail.com>
wrote in <0c4876d4-d487-40d0-9d26-0721e809a35a(a)w15g2000pro.googlegroups.com>:

> OK - so tests for Floating point ">",">=","<" and "<=" are subject to
> the same processor-dependencies as a direct or indirect test for "=="?

In a word, yes. While there are cases where floating-point can
return exact representations of a number (e.g. integers within a finite
range) the vast majority of numbers are not exactly representable and the
floating-point _approximation_ you arrive at for those numbers may well
differ depending on the computation chain used to arrive at the number.

--
Ivan Reid, School of Engineering & Design, _____________ CMS Collaboration,
Brunel University. Ivan.Reid@[brunel.ac.uk|cern.ch] Room 40-1-B12, CERN
KotPT -- "for stupidity above and beyond the call of duty".
From: dpb on
analyst41(a)hotmail.com wrote:
....

> OK - so tests for Floating point ">",">=","<" and "<=" are subject to
> the same processor-dependencies as a direct or indirect test for "=="?

I'd amplify the other remark by the non-technical statement of "of course".

Consider that the branch to be taken is dependent in the end on the
comparison of whether either fp quantity A or fp quantity B is, or is
not, different in a particular direction from the other in that last bit
of precision. Fundamentally, that's no different than whether they're
equal to the last bit or not as to whether the comparison falls one side
or the t'other.

--
From: Carlie Coats on
Dr Ivan D. Reid wrote:
> On Sun, 1 Aug 2010 10:25:33 -0700 (PDT), analyst41(a)hotmail.com
> <analyst41(a)hotmail.com>
> wrote in<0c4876d4-d487-40d0-9d26-0721e809a35a(a)w15g2000pro.googlegroups.com>:
>
>> OK - so tests for Floating point ">",">=","<" and"<=" are subject to
>> the same processor-dependencies as a direct or indirect test for "=="?
>
> In a word, yes. While there are cases where floating-point can
> return exact representations of a number (e.g., [small integers]...

ISTR that on some early vector machines, even these small integers
would fail (something like "x=10.0; print *,x" would return maybe
9.9999999999999999). And comparisons for exact-10 might well fail.

;-(

-- Carlie Coats