Per Bothner scripsit:
> Point taken. Though it seems questionable to call soemthing a "flonum"
> if it doesn't use a floating-point representation - that is after all
> the etymology of "flonum".
The etymology of "etymology" is "true meaning", but etymologies often
have nothing to do with current meaning. :-)
> If you're talking about the = operator (rather than eqv?) then
> it must certainly check for a NaN rather than just doing a bitwise
> comparison. (Also (+ +0.0 -0.0) should also be #t.)
> I believe current hardware does that. Certainly that is
> what numerical == in Java, C#, and probably other languages have to do.
Numeric equality (Java/C# ==, C/C++ == when running on IEEE hardware,
Scheme = and fl=) behaves quite differently: (= +nan.0 +nan.0) is and
must be #f in accordance with the IEEE standard. (Quick tests show that
Java and C and Chicken Scheme do behave this way.) The same applies to
the != function, which Scheme does not have: it too must return #f.
However, we have more flexibility about the behavior of eqv? when both
arguments are flonums. It could return #f if either argument is a NaN,
as = does; or return #t iff the bit patterns being compared are the same;
or return #t if both arguments are NaNs, whether the bit patterns are
the same or different. (Chicken defers to =, and takes the first option.)
> Not quite. It says "indeterminate". It means that as the result of a
> computation NaN represent an indeterminate/unknown real value. However,
> NaN as a value (datum) in its own right is 100% exact: It is a value
> with a certain representation.
The same is true of all inexact numbers: each one of them is itself exact,
they are merely flagged as being the result of an inexact computation
or as having been inexact when they arrived from outside the program.
> >In Java, at any rate, NaN == NaN is always false, for Java
> >has no identity for numbers other than numeric equality.
>
> Not as a binary operator. But you can use Double.doubleToLongBits to
> convert a double to its bit representation (as a long), or you can use
> Double.equals to compare two Double objects bit-for-bit.
The former method works, but the latter does not: given two Doubles
representing NaNs, Double.equals will return false.
--
So that's the tune they play on John Cowan
their fascist banjos, is it? cowan_at_ccil.org
--Great-Souled Sam http://www.ccil.org/~cowan
Received on Wed Sep 20 2006 - 14:05:26 UTC