[Scheme-reports] ballot question #229: EQV? and NaN

[will@x]

The outcome of ballot question #229 cannot be allowed to stand
because it doesn't make technical sense.  There were at least
four technical errors in the wording of that ballot question,
and the R6RS-compatible (and most sensible) semantics was not
even listed among the candidate semantics.

Bradley Lucier voted for and described the R6RS-compatible (and
most sensible) semantics for EQV? and NaN.  It may be possible
for WG1 to adopt that semantics as a clarification in response
to the technical facts that Lucier and I are bringing to your
attention, which would be fine with me.  Otherwise this issue
will need to be added to Ballot 5.

As Bradley Lucier noted in his comments, the +nan.0 notation of
R6RS Scheme is used for all of the NaNs that may be supported
by an implementation of R6RS Scheme.  In implementations that
use IEEE double precision arithmetic, there are over 2^50
distinct NaN values that may all print as +nan.0.  From R6RS
section 4.2.8:

    The +nan.0 literal represents the NaN that is the result
    of (/ 0.0 0.0), and may represent other NaNs as well.

That "may represent other NaNs as well" is not some theoretical
possibility:  It is the usual practice.

Yet ballot question #229 was written as though +nan.0 denotes
a single value.  It does not.  That means the semantics for
which the majority voted in ballot 4 doesn't even make sense
as written.

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.

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?."  In reality, any R5RS-conforming
implementation of EQV? has to handle inexact reals specially.
In implementations that represent their inexact reals using
IEEE-754 binary floating point, there are at least two
different ways for EQV? to compare inexact reals.  Comparing
inexact reals via = produces the "different" behavior, but
comparing the bits produces the "same*" behavior that Lucier
described.  The "same*" behavior doesn't imply any more
special handling than the "different" behavior, and is likely
to be at least as fast as the "different" behavior.

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 suspect that the
person(s) who ran the tests was unaware that the behavior of
NaNs is system-specific:  It depends on the hardware and the
numerical libraries as well as upon the parts of the system
that are under the control of an implementor of Scheme.
What's more, the result depends on the particular NaNs that
are involved in the test.  Here's an example from Larceny
running on a Macintosh:

> (begin (define nan0 +nan.0)
         (define nan1 (/ 0.0 0.0))
         (define nan2 (- +inf.0 +inf.0)))

> (eqv? nan0 nan0)
#t

> (eqv? nan1 nan1)
#t

> (eqv? nan2 nan2)
#t

> (eqv? nan0 nan1)
#f

> (eqv? nan0 nan2)
#f

> (eqv? nan1 nan2)
#t

> (list nan0 nan1 nan2)
(+nan.0 +nan.0 +nan.0)

Clearly nan0 and nan1 are two distinct values, even though
both print as +nan.0.  On different hardware, nan0 and nan1
might be the same value, even in Larceny.  Although nan1 and
nan2 are the same NaN on this particular hardware, they might
be distinct NaNs on different hardware, even in Larceny.

That's the R6RS semantics.  It's the "same*" semantics that
Bradley Lucier described.

It's apparent that the author(s) of ballot question #229
thought they were describing the R6RS semantics when they
specified the "same" semantics, but they weren't.

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.

Will

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