Alex Shinn <alexshinn@gmail.com> writes:
> On Tue, May 8, 2012 at 10:55 AM, Mark H Weaver <mhw@netris.org> wrote:
>> Alex Shinn <alexshinn@gmail.com> writes:
>>> On Tue, May 8, 2012 at 8:42 AM, Mark H Weaver <mhw@netris.org> wrote:
>>>> John Cowan <cowan@mercury.ccil.org> writes:
>>>>> Mark H Weaver scripsit:
>>>>>
>>>>>> 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?
>>>
>>> It must be unspecified in R7RS because R7RS
>>> does not require that implementations distinguish
>>> between 0.0 and -0.0, nor that they provide +inf.0
>>> or -inf.0.
>>
>> That's why I qualified my statement with "on platforms with signed
>> zeroes".  All I am advocating is that EQV? be based on operational
>> equivalence, i.e. that we mandate (eqv? 0.0 -0.0) => #true if and only
>> if 0.0 and -0.0 are operationally equivalent.
>
> The problem is an implementation may have a
> different representation for -0.0 but still not
> support +/-inf.0.

Division is not the only operator that distinguishes 0.0 and -0.0.
Signed zeroes are also relevant for any operation involving branch cuts
along the real or imaginary axes.

When I have written "on platforms with signed zeroes", that is a
shorthand for "in implementations where 0.0 and -0.0 are not
operationally equivalent".  If 0.0 and -0.0 are indistinguishable, then
effectively the implementation does not have signed zeroes.

> Trying to to list every case manually would result in a long chain of
> if/then/else statements.  It's much better if the desired results fall
> out naturally from a simple rule.

Agreed, and the simple rule is the one given in the R3RS:

   The eqv? procedure implements an approximation to the relation of
   operational equivalence.  It returns #t if it can prove that obj1 and
   obj2 are operationally equivalent.  If it can't, it always errs on
   the conservative side and returns #f.

where operational equivalence is defined as follows:

   Two objects are operationally equivalent if and only if there is no
   way that they can be distinguished, using Scheme primitives other
   than eqv? or eq? or those like memq and assv whose meaning is defined
   explicitly in terms of eqv? or eq?.  It is guaranteed that objects
   maintain their operational identity despite being named by variables
   or fetched from or stored into data structures.

For the usual numeric representations, an implementation should be able
to determine whether two numbers are operationally equivalent.  However,
it should be noted that there are some exotic numeric representations
such as infinite-precision reals (e.g. based on continued fractions or
continued logarithms) where operational equivalence cannot always be
proved.  The R3RS wording above allows for this case.

> This is why we're revisiting all eqv? tickets as a single item in the
> next ballot - we should have a single consistent rule and stick to it.

Agreed.

      Mark

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