Re: Inexact floating-point compare

In article <[EMAIL PROTECTED]>, Dik T. Winter <[EMAIL PROTECTED]> wrote:
>In article <[EMAIL PROTECTED]> "Fred J. Tydeman" <[EMAIL PROTECTED]> writes:
> > Does anyone know of any machines, that have a floating-point compare
> > instruction, where that instruction is not exact?  That is, some of
> > the value bits of the floating-point numbers are ignored.  Or, if
> > the compare is done internally as a subtract, the subtract results in
> > an underflow (so two different numbers near the minimum normalized
> > value, when subtracted produce a subnormal number) that is then 
> > flushed to zero, so compare equal.
>
>Yup.  But modern machines (IEEE) do not.  ...

A fair proportion of 'IEEE' machines, aren't.  A very common feature
is to support denormalised numbers optionally, in software, or not at
all.  In all cases, this will usually lead to the comparison of two
different denormalised numbers treating them as equal.

I don't know of any current ones that are inconsistent, so you can
create such numbers only by creating the numbers in as bit patterns
(e.g. reading a binary file), but I haven't checked.  Incidentally,
of of CDF's bugs is that it does not handle this case correctly,
or at least it used not to.  There MAY be some systems that are
inconsistent in this respect.

[ In a consistent system, two numbers that compare equal will have
an equivalent effect when used in any calculation. ]


Regards,
Nick Maclaren.