guile-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Equality predicates, signed zeroes, R5RS and R6RS


From: Mark H Weaver
Subject: Equality predicates, signed zeroes, R5RS and R6RS
Date: Mon, 31 Jan 2011 14:53:29 -0500
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux)

An issue has come to my attention that deserves wider discussion.

Since at least Guile 1.8, (= 0.0 -0.0) has returned #t
but (eqv? 0.0 -0.0) has returned #f, and this is still the case.

PLT Scheme agrees with us that (eqv? 0.0 -0.0) is #f, but MIT/GNU Scheme,
SCM, Chicken, and Gauche all return #t in this case.

Our current behavior violates the R5RS but is required by the R6RS.
The R5RS requires that `eqv?' and `=' must agree for numbers of the same
exactness.

The R6RS requires that `eqv?' must return #f for arguments that yield
different results (in the sense of eqv?) when passed as arguments to any
other procedure that can be defined as a finite composition of Scheme’s
standard arithmetic procedures.

Since the R6RS also requires that (/ 0.0) yields +inf.0, and IEEE 754
requires not only this but also that (/ -0.0) yields -inf.0, that
implies that (eqv? 0.0 -0.0) must be #f.

IEEE 754 also requires that (= 0.0 -0.0) must return #t, and indeed this
is the only sane option.  Therefore I see no way to be compliant with
both the R5RS and the R6RS at the same time.

Personally, although I don't agree with the R6RS on everything, I think
they got this part right.  It's useful to have an equality predicate
that can distinguish numbers that are distinguishable by other numerical
operations.

Given that everyone agrees that `eqv?' must distinguish 0 from 0.0, it
is already not useful as a numerical `='.  Any program that uses it this
way is asking for trouble.  Therefore, I don't have qualms about keeping
our existing behavior, namely that (eqv? 0.0 -0.0) returns #f.

What do you think?

      Mark



reply via email to

[Prev in Thread] Current Thread [Next in Thread]