[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Scheme-reports] EQV? on numbers should be based on operational equivalence
On Tue, May 8, 2012 at 1:59 PM, Mark H Weaver <mhw@x> wrote:
> Alex Shinn <alexshinn@x> writes:
>> On Tue, May 8, 2012 at 10:55 AM, Mark H Weaver <mhw@x> wrote:
>>> Alex Shinn <alexshinn@x> writes:
>>>> On Tue, May 8, 2012 at 8:42 AM, Mark H Weaver <mhw@x> wrote:
>>>>> John Cowan <cowan@x> 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
>>>> 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.
If they have different written representations, then they _are_
distinguishable, at least by the R3RS definition of eqv? (but
not by the R6RS definition) assuming the R3RS definition applies
to all primitives provided by the implementation, not the
standard (on that point R3RS is ambiguous so we still need
some work in coming up with a good rule).
We haven't generally made a distinction for a result being
"implementation-defined", simply saying "unspecified." Thus
with either the R3RS or current R7RS, for the specific question
(= 0.0 -0.0) => ?
the ? would be written "unspecified". That is, the semantics
are clearly defined by the standard but the effect varies per
implementation, so from a point of view of portability you
cannot reliably get a consistent result from this expression.
Scheme-reports mailing list