John Cowan <cowan@mercury.ccil.org> writes:
> 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.

Are you sure that all NaNs are operationally equivalent?  IEEE 754
defines two different kinds of NaN: quiet NaNs and signalling NaNs.

Keep in mind that any operation involving NaNs that the standard leaves
unspecified is a place where a conforming implementation might
distinguish between NaNs with different bit patterns.

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

Yes of course, and if they are all the same, then they are all
operationally equivalent and thus should all be considered EQV?
AFAICT, nothing I wrote contradicts that.

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

Yes.  What does that have to do with what I wrote?

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

Indeed, and that's why they're not operationally equivalent on systems
with signed zeroes.

I don't see how any of this relates to my question above.
Do you have an answer to my question?

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

How would you suggest implementing memoization in a portable R7RS
program?

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

Again, I'm not sure that you can count on this because of signalling vs
quiet NaNs, but if it's truly the case that all NaNs are
indistinguishable on a particular implementation, then
(eqv? +nan.0 +nan.0) should return #true.

     Mark

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