Re: [Scheme-reports] EQV? on numbers should be based on operational equivalence

[John Cowan <cowan@x>]

Mark H Weaver scripsit:

> Unfortunately, the R4RS removed the term "operational equivalence" and
> retained only the R3RS elaborations.  Nonetheless, EQV? on numbers is
> consistent with operational equivalence in _every_ existing Scheme
> standard, if one only considers the numbers that are discussed in the
> standard.  The R7RS would be the first to deviate from this.

That turns out not to be the case.  In R6RS we are explicitly told tht
(eqv? +nan.0 +nan.0) => undefined, yet the two instances of +nan.0 are
operationally equivalent in terms of standard R6RS procedures.

> *** Looking at it from another angle:
> 
> Is there _any_ job for which the right tool is a numerical equality
> predicate that regards 0 and 0.0 as unequal, but 0.0 and -0.0 as equal?

"Things are seldom what they seem / Skim milk masquerades as cream /
Highlows pass as patent leathers / Jackdaws strut in peacock's feathers."

The first point to make is that 0, 0.0, and -0.0 may be exactly the same
thing in systems that don't have inexact numbers (SigScheme, Dream, Oaklisp,
Owl Lisp).

The second is that they are always going to be equal in the sense of =.

The third is that if 0.0 and -0.0 are distinct, then they cause arithmetic
procedures to return different answers: as noted in R6RS, (angle -1.0+0.0i)
is pi, whereas (angle -1.0-0.0i) is -pi.

> In particular, on platforms with signed zeroes, the R7RS should mandate
> that (eqv? 0.0 -0.0) => #false.

R6RS mandates that, but R7RS currently leaves it unspecified.

> What about NaNs?  If we allow (eqv? +nan.0 +nan.0) => #false for NaNs
> with the same bit patterns, then memoization tables would accumulate
> redundant entries for NaN arguments.  I would argue that although we
> cannot mandate a specific answer for (eqv? +nan.0 +nan.0), we should
> mandate that the answer be consistent with operational equivalence.  On
> IEEE 754 platforms, this implies that the result should be #true if both
> NaNs have the same bit patterns, and #false for NaNs with different bit
> patterns if they are distinguishable by standard numerical procedures.

I believe that they are not: no R7RS (or R6RS, for that matter) standard
procedure can distinguish between one NaN and another.

-- 
John Cowan    cowan@x    http://ccil.org/~cowan
Heckler: "Go on, Al, tell 'em all you know.  It won't take long."
Al Smith: "I'll tell 'em all we *both* know.  It won't take any longer."

_______________________________________________
Scheme-reports mailing list
Scheme-reports@x
http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports