Re: Reverting eqv? behavior for signed zeros and nans to 1.6 semantics

[Per Bothner]

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