[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Reverting eqv? behavior for signed zeros and nans to 1.6 semantics
From: |
Per Bothner |
Subject: |
Re: Reverting eqv? behavior for signed zeros and nans to 1.6 semantics |
Date: |
Tue, 18 Jul 2006 05:38:29 -0700 (PDT) |
User-agent: |
SquirrelMail/1.4.6-5.fc5 |
> | From: Marius Vollmer <address@hidden>
> | Specifically, 'eqv?' would be changed to return '#t' when comparing
> | negative and positive zero:
> |
> | (eqv? 0.0 -0.0) => #t
I missed the explanation for why this might be desirable.
I don't think it is the Right Thing. Arguments from
R5RS are irrelevant, since it doesn't consider NaNs
and infinities. Our goal should be to fix this.
>
> Okay!
>
> | and should return #f for nans:
> |
> | (eqv? +nan.0 +nan.0) => #f
>
> IEEE-754 apparently chose to overload the floating-point equality
> operator to detect NaNs to avoid having to define new floating-point
> predicates. Guile already has a nan predicate. 754's low-level hack
> should not be exposed in Scheme.
>
> In the description of EQ?, R5RS states:
>
> `Eq?''s behavior on numbers and characters is
> implementation-dependent, but it will always return either true or
> false, and will return true only when `eqv?' would also return true.
>
> So if (eqv? +nan.0 +nan.0) returns false, then (eq? +nan.0 +nan.0)
> cannot return true and must return false.
It seems clear that (eq? +nan.0 +nan.0) must be unspecified,
and hence (eqv? +nan.0 +nan.0) cannot be defined to be #f.
Hence it should be defined as #t. To me that is the correct
definition: eqv? between floating-point numbers returns #t
iff they bit-for-bit equal (and thus implicitly the same
precision).
eqv? means the same value; = is numerically equal.