will@ccs.neu.edu scripsit:

> Bradley Lucier voted for and described the R6RS-compatible (and most
> sensible) semantics for EQV? and NaN.

I concede that I was wrong to say that "same" is the R6RS semantics.
However, on closer examination I think that R6RS leaves the semantics of
EQV? comparison between any NaN and any inexact number (including NaN)
wide open.

Here is what R6RS has to say about the semantics of EQV? when comparing
numbers:

1) Return #t if "obj1 and obj2 are both exact number objects and are
numerically equal (see =, section 11.7)."  This rule is irrelevant since
NaNs are inexact.

2) Return #t if "obj1 and obj2 are both inexact number objects, are
numerically equal (see =, section 11.7), and yield the same 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."  This rule is irrelevant since NaNs are not numerically
equal to any number.

3) Return #f if "one of obj1 and obj2 is an exact number object but the
other is an inexact number object."  This rule is irrelevant since we are
comparing a NaN with an inexact number.

4) Return #f if "obj1 and obj2 are rational number objects for which
the = procedure returns #f."  This rule is irrelevant since NaNs are
non-rational.

5) Return #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."

Rule 5 could only be relevant (and would prescribe the "different"
semantics) if it could be shown that at least two compositions of
Scheme's standard arithmetic procedures produces different results when
applied to NaNs of different bit patterns (which in Scheme terms would
mean of different origins).  I do not believe it can be so shown.

> Yet ballot question #229 was written as though +nan.0 denotes a single
> value.  It does not.

Unless someone can meet the demand above, +nan.0 is only a single value in
Scheme terms because of the identity of indiscernibles.

> The second technical mistake in the wording of ballot question #229
> is its assertion that the "same" semantics "is what R6RS specifies."
> That's just not true.  R6RS specifies the "same*" semantics for which
> Bradley Lucier voted.

I agree with the first point, but dispute the second, as shown above.

> The third technical mistake came in the description of the "different"
> semantics, which says that semantics yields "the behavior that results
> for any R5RS implementation that adds support for +nan.0 as an IEEE
> float without any special handling for it in eqv?."

If we assume that R5RS = returns #f when one argument is a NaN (which
complies with R6RS and is always true in practice), then the rules for
EQV? are:

1') Return #t if obj1 and obj2 are both numbers, are numerically equal
(see =, section 6.2), and are either both exact or both inexact.  This
rule is irrelevant because a NaN cannot be = to any number under the
assumption above.

2') Return #f if one of obj1 and obj2 is an exact number but the other
is an inexact number.  This rule is irrelevant because we are comparing
NaNs with inexact numbers.

3') Return #f if obj1 and obj2 are numbers for which the = procedure
returns #f.

Rule 3' requires R5RS implementations (given the above assumption)
to return #f when one argument is a NaN and the other is a number.
In fact, many R5RS implementations return #t to (eqv? +nan.0 +nan.0).
I should however have tested two NaNs of different origin to see if it
made any difference.

> The fourth technical mistake came in the survey of current practice,
> which says that Chez Scheme and Ikarus return #t but Larceny returns
> #f.  The ballot question isn't clear on the expression involved, but
> all three of the systems I mentioned implement the R6RS semantics.

I implemented the simplest possible test: I asked the REPLs for the
values of (eqv? +nan.0 +nan.0) and (eqv? +nan.0 0.0).

> It seems to me there are two ways for WG1 to proceed:  You could count
> all votes for the "same" semantics as votes for the "same*" semantics,
> or you could repair the question and revote.  Going with the "same"
> semantics as described in ballot question #229 is a non-starter.

I grant that we must revote because of my errors in description.
However, my arguments for the "same" semantics, namely that +nan.0 is
a single Scheme value no matter how many representations it has, and
that it is appropriate to be able to use EQV? to determine if a NaN is a
member of a data structure or not, still stand.

--
All Norstrilians knew that humor was            John Cowan
"pleasurable corrigible malfunction".          cowan@ccil.org
        --Cordwainer Smith, Norstrilia

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