Equality predicates, signed zeroes, R5RS and R6RS

Equality predicates, signed zeroes, R5RS and R6RS

[Mark H Weaver]

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

Re: Equality predicates, signed zeroes, R5RS and R6RS

[Mike Gran]

> From:Mark H Weaver <mhw@netris.org>
> To:guile-devel@gnu.org
> Cc:Andy Wingo <wingo@pobox.com>; Taylor R Campbell <campbell@mumble.net>
> Sent:Monday, January 31, 2011 11:53 AM
> Subject:Equality predicates, signed zeroes, R5RS and R6RS
> 
> 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.

As an aside, as of a couple of months ago, it was possible to create
the following seven versions of zero in Guile using the default reader.

0, ±0.0, ±0.0±0.0i 

Note that there is no way to make negative zero integer (-0).  And
there are no zero rationals:  ±0/2, for example.

Each scheme has its quirks.

MzScheme 4.1 would let you create complex numbers with integer representation
real and float representation imaginary parts: 0+0.0i, for example. The integer
parts can only be positive zero and the float parts can be ±0.0.

But as a physicist, I declare that this is all madness. 

-Mike

Re: Equality predicates, signed zeroes, R5RS and R6RS

[Mark H Weaver]

Mike Gran <spk121@yahoo.com> writes:
> As an aside, as of a couple of months ago, it was possible to create
> the following seven versions of zero in Guile using the default reader.
>
> 0, ±0.0, ±0.0±0.0i 

Really?  I don't understand how this could have happened.  mem2complex
uses scm_make_rectangular to create complex numbers, and
scm_make_rectangular calls scm_c_make_rectangular, which creates a real
if the imaginary part is zero.

I looked at the history, and I don't see any relevant changes to this
behavior in the last several years at least, unless the default reader
formerly used something other than mem2complex, and created the numbers
without scm_c_make_rectangular.

In any case, I will soon submit patches to allow us to create all seven
of these zeroes again, as required by R6RS.

> But as a physicist, I declare that this is all madness. 

I agree that it doesn't sit entirely well with me either.  I would like
for computer languages to be mathematically rigorous in their behavior.
However, having looked closely at the rationale behind the signed
zeroes, I can see why the designers of IEEE 754 mandated them.  They are
important when working with functions involving branch cuts, as the cuts
are approached from either side and underflow may change a small number
into a zero.  Making robust numerical programs is unfortunately a messy
business.

     Best,
      Mark

Re: Equality predicates, signed zeroes, R5RS and R6RS

[Mike Gran]

> From:Mark H Weaver <mhw@netris.org>
> To:Mike Gran <spk121@yahoo.com>
> Cc:"guile-devel@gnu.org" <guile-devel@gnu.org>
> Sent:Monday, January 31, 2011 2:42 PM
> Subject:Re: Equality predicates, signed zeroes, R5RS and R6RS
> 
> Mike Gran <spk121@yahoo.com> writes:
> > As an aside, as of a couple of months ago, it was possible to create
> > the following seven versions of zero in Guile using the default reader.
> >
> > 0, ±0.0, ±0.0±0.0i 
> 
> Really?  I don't understand how this could have happened.  mem2complex
> uses scm_make_rectangular to create complex numbers, and
> scm_make_rectangular calls scm_c_make_rectangular, which creates a real
> if the imaginary part is zero.

Sorry, I was completely wrong with that.  I was looking at the output for
few different Schemes, and I got confused.

As you say, Guile 2.0 only gets you, 0 and ±0.0. 

Sorry for the noise.
-Mike

Re: Equality predicates, signed zeroes, R5RS and R6RS

[Andy Wingo]

On Mon 31 Jan 2011 20:53, Mark H Weaver <mhw@netris.org> writes:

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

This sounds OK to me.  I don't have a horse in the race, but the
argument that (eqv? 0 0.0) => #f is convincing, especially given the
0.0-or-0 games that many procedures are allowed to play.

Andy
-- 
http://wingolog.org/