Per Bothner skrev:
> Jens Axel S?gaard wrote:
>> Marcin 'Qrczak' Kowalczyk skrev:
>>> John Cowan <cowan_at_ccil.org> writes:
>>>
>>>>> Is there any scenario where you'd want anything other than:
>>>>>
>>>>> (eqv? +nan.0 +nan.0) => #t
>>>> Eqv? on unboxed floats can be implemented by bitwise comparison
>>>> rather than floating-point equality.
>>>
>>> And this is why it should be #t.
>>
>> There is more than one bit-pattern for +nan.0.
>
> No. The bit-pattern for +nan.0 is not fully specified by IEEE,
> and hence should not be specified by R6RS, but for any given
> implementation the literal +nan.0 can only evaluate to a
> single bit-pattern.
I see what you mean. For some reason I was thinking of
(let ([nan1 <expression-producing-a-nan>]
[nan2 <expression-producing-a-nan>])
(eqv? nan1 nan2))
> This is not inconsistent with allowing
> an implementation to interpret multiple bit-patterns as NaN.
> However, +nan.0 is the canonical/default NaN, and it cannot
> randomly change value during execution.
Unless we leave it unspecified, whether eq? must return
#t or #f on nan-values - and doesn't explicitly mention
that +nan.0 must evaluate to the same bit pattern every
time. That way it would be okay, to compile +nan.0 to
an arithmetical expression producing a nan-value.
Anyways, I am sure I can live with both choices.
--
Jens Axel S?gaard
Received on Thu Nov 23 2006 - 16:59:33 UTC