Usenet.com

www.Usenet.com

Group Index

Comp Thread Archive from Usenet.com

<-- __Chronological__ --> <-- __Thread__ -->

Re: Inexact floating-point compare



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.  The CDC Cyber was one,
and in two ways.  The machine had four compare instructions for the
registers that could hold a floating point number, "zero", "non-zero",
"positive, including +0", "negative, including -0".  To compare you
subract, normalise and compare with 0.  The normalisation would
indeed flush subnormal numbers to 0.  But there was another problem.
The result of the subtraction had an exponent equal to the largest
of the two exponents of the operands.  This could lead to the loss
of the least significant bit of the subtraction result when the
exponents of the operands differed by 1.  And that bit *could* be
the only significant bit of the result.  E.g. 2^48 (^ means to the
power here) and (2^48 - 1) would compare equal (48 bits mantissa).

For (in)equality you could always do a bitwise exclusive or of the two
operands, but that is not possible with other comparisons.
-- 
dik t. winter, cwi, kruislaan 413, 1098 sj  amsterdam, nederland, +31205924131
home: bovenover 215, 1025 jn  amsterdam, nederland; http://www.cwi.nl/~dik/



<-- __Chronological__ --> <-- __Thread__ -->


Usenet.com



Please check out one of the premium Usenet Newsgroup Service Providers below for access to Usenet.