[r6rs-discuss] [Formal] Unclear how equality predicates behave on NaN

[Per Bothner]

John Cowan wrote:
> Per Bothner scripsit:
> 
>>> This would not work reliably in a (hypothetical) system in which
>>> inexact numbers are represented as ratnums with an "inexact" bit
>>> and in which ratnums do not have to be in lowest terms.
>> Then they wouldn't be flonums.
> 
> Au contraire.  Flonums are simply a subset (proper or improper) of the
> inexact real numbers, possibly enhanced with some other members
> such as +inf.0, -inf.0, and +nan.0.  R6RS section 2.1 explicitly says
> that flonums need not have floating-point representations.

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

> Note also that there is no requirement that irrational real numbers
> be representable within the Scheme number system, and most Schemes
> do not represent them, with the exception of the same three special cases.
> 
>>> But what's really at stake here is that users shouldn't expect
>>> reliable results from eqv? on two NaNs generated by different
>>> processes (where reading "+nan.0" counts as a process), even
>>> on a single system.
>> Yes, they should.
> 
> Well, we'll argue that point (said Jack).  To do this, the definition
> of flonum equality on systems where flonums are IEEE in nature must
> check each argument to see if it is a NaN rather than simply doing
> a bitwise comparison.

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.

 > Fair enough if that's what people want.

Well, it's what IEEE specifies.

If you're talking about the eqv? function, then it does not need to
check for NaN - it just just dies the bit-or-bit comparison.

>>> This conforms to the definition of NaN
>>> in R6RS as a number so inexact that it could be any real number
>>> at all.
>> That is not what NaN is.  A NaN is a concrete value with a concrete
>> representation.  (According to IEEE there can be many NaN values but
>> that doesn't change the argument.)  You can test for it.  Java and C#
>> have a isNaN math; C (at least glibc) has an fpclassify function that
>> can return FP_NAN.
> 
> Well, it's what Section 2.4 says a NaN is,

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.

> and AFAIK neither Java nor
> C prescribes whether NaNs with different representations are or are not
> identical.  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.
  --
	--Per Bothner
per at bothner.com   http://per.bothner.com/