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/
Received on Wed Sep 20 2006 - 13:27:08 UTC