bug in eqv?

bug in eqv?

[Aubrey Jaffer]

bash-2.05b$ guile --version
Guile 1.8.0 ...
bash-2.05b$ guile
guile> (= 0.0 -0.0)
#t
guile> (eqv? 0.0 -0.0)
#f

According to R5RS section "6.1 Equivalence predicates":

     The `eqv?' procedure returns #t if:

        * OBJ1 and OBJ2 are both numbers, are numerically equal (see
          `=', section *note Numbers::), and are either both exact or
          both inexact.

Because (= 0.0 -0.0) is #t, (eqv? 0.0 -0.0) must be #t.


_______________________________________________
Bug-guile mailing list
Bug-guile@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-guile

Re: bug in eqv?

[Kevin Ryde]

Aubrey Jaffer <agj@alum.mit.edu> writes:
>
> Because (= 0.0 -0.0) is #t, (eqv? 0.0 -0.0) must be #t.

Ah dear, thanks.  Bit too much creativity with the nans and infs.


_______________________________________________
Bug-guile mailing list
Bug-guile@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-guile

Re: bug in eqv?

[Marius Vollmer]

Kevin Ryde <user42@zip.com.au> writes:

> Aubrey Jaffer <agj@alum.mit.edu> writes:
> >
> > Because (= 0.0 -0.0) is #t, (eqv? 0.0 -0.0) must be #t.
> 
> Ah dear, thanks.  Bit too much creativity with the nans and infs.

Hmm.  I think SRFI 77 (Preliminary Proposal for R6RS Arithmetic) would
require (eqv? 0.0 -0.0) => #f, since it says

    The eqv? procedure returns #f if obj1 and obj2 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.

and, for example, (eqv? (flatan2 -1.0 -0.0) (flatan2 1.0 -0.0)) => #f.
See also "Lucier's Proposal" in the SRFI 77 document.

I originally copied the behavior of PLT Scheme and I'd say it is OK to
follow SRFI 77 for the behavior of negative zero, infinities and NaNs
now that it exists.

(We get (integer? +inf.0) => #f wrong, then, and probably other
things.)

-- 
GPG: D5D4E405 - 2F9B BCCC 8527 692A 04E3  331E FAF8 226A D5D4 E405


_______________________________________________
Bug-guile mailing list
Bug-guile@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-guile

Re: bug in eqv?

[Aubrey Jaffer]

 | From: Marius Vollmer <mvo@zagadka.de>
 | Date: 22 Mar 2006 01:52:40 +0200
 | 
 | Kevin Ryde <user42@zip.com.au> writes:
 | 
 | > Aubrey Jaffer <agj@alum.mit.edu> writes:
 | > >
 | > > Because (= 0.0 -0.0) is #t, (eqv? 0.0 -0.0) must be #t.
 | > 
 | > Ah dear, thanks.  Bit too much creativity with the nans and infs.
 | 
 | Hmm.  I think SRFI 77 (Preliminary Proposal for R6RS Arithmetic) would
 | require (eqv? 0.0 -0.0) => #f, since it says
 | 
 |     The eqv? procedure returns #f if obj1 and obj2 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.
 | 
 | and, for example, (eqv? (flatan2 -1.0 -0.0) (flatan2 1.0 -0.0)) => #f.
 | See also "Lucier's Proposal" in the SRFI 77 document.

SRFI-77 is the most preliminary of proposals, and guaranteed to be
withdrawn.  If you are determined that Guile chase SRFI phantoms, then
be sure to note this variance from R4RS and R5RS in the documentation.

 | I originally copied the behavior of PLT Scheme

http://swiss.csail.mit.edu/~jaffer/III/RAWI shows that there are many
differences in implementations' numerical behavior.  One could justify
nearly any choice if the act of copying were, in itself, a
justification.

 | and I'd say it is OK to follow SRFI 77 for the behavior of negative
 | zero, infinities and NaNs now that it exists.

bash-2.05b$ mzscheme
Welcome to MzScheme version 209, Copyright (c) 2004 PLT Scheme, Inc.
> (eqv? -0.0 0.0)
#t

bash-2.05b$ mzscheme-301
Welcome to MzScheme version 301, Copyright (c) 2004-2005 PLT Scheme Inc.
> (eqv? -0.0 0.0)
#f
> (equal? -0.0 0.0)
#f

bash-2.05b$ guile
guile> (eqv? -0.0 0.0)
#f
guile> (equal? -0.0 0.0)
#t

SRFI-77 does not mention equal?, so R5RS would still be in effect:

 -- library procedure: equal? obj1 obj2
     `Equal?' recursively compares the contents of pairs, vectors, and
     strings, applying `eqv?' on other objects such as numbers and
     symbols.  A rule of thumb is that objects are generally `equal?'
     if they print the same.  `Equal?' may fail to terminate if its
     arguments are circular data structures.

If -0.0 and 0.0 print differently, then there is no support for 
(equal? -0.0 0.0) ==> #t.

 | (We get (integer? +inf.0) => #f wrong, then, and probably other
 | things.)

Mzscheme also does (integer? +inf.0) ==> #t.  Does that make it right?


_______________________________________________
Bug-guile mailing list
Bug-guile@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-guile

Re: bug in eqv?

[Kevin Ryde]

Aubrey Jaffer <agj@alum.mit.edu> writes:
>
> SRFI-77 is the most preliminary of proposals, and guaranteed to be
> withdrawn.

Yep.  Seems to me the idea of base r5rs is reasonably clear (not
crystal clear, but near enough) that eqv? is the same as = on numbers.
Keeps the heirarchy of comparisons clean too.

>  -- library procedure: equal? obj1 obj2
>      `Equal?' recursively compares the contents of pairs, vectors, and
>      strings, applying `eqv?' on other objects such as numbers and
>      symbols.  A rule of thumb is that objects are generally `equal?'
>      if they print the same.  `Equal?' may fail to terminate if its
>      arguments are circular data structures.
>
> If -0.0 and 0.0 print differently, then there is no support for 
> (equal? -0.0 0.0) ==> #t.

I would read it that equal? is supposed to be the same as eqv? on
numbers, and the bit about printing is only an aid to understanding
the recursion (and not a terribly helpful one really).


_______________________________________________
Bug-guile mailing list
Bug-guile@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-guile