John Cowan wrote:
> Per Bothner scripsit:
>
>> I'd go so far as to specify:
>> (eqv? obj1 obje2) is #t if:
>> obj1 and obj2 are flonums with the same representation
>> and are bit-for-bit equal.
>> (eqv? obj1 obje2) is #f if:
>> obj1 and obj2 are flonums with the same representation
>> and are not bit-for-bit equal.
>
> 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.
> 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.
> 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.
>> This is a useful definition. It's hard to imagine a
>> case where you'd want anything else, assuming flonums
>> are they are actually used in today's software and
>> hardware.
>
> Not always a good assumption: low-end chips in embedded
> systems often have no flonum instructions at all.
But I just gave a specification for *flonum*. If flonums don't
exist, then the specification doesn't apply.
(Also, it is of course irrelevant whether flonums are implemented
in hardware or by a software library.)
--
--Per Bothner
per_at_bothner.com http://per.bothner.com/
Received on Wed Sep 20 2006 - 12:08:08 UTC