Thanks Will, I wish you had been available to review
the ballot items before we voted :)

Many of the tickets are written informally and it's my
job to clean them up before putting them on the ballot -
this isn't the first time I let a badly formed item through.

I'll modify the draft to use R6RS semantics, and
re-open this for confirmation in the next ballot.

--
Alex

On Thu, Sep 29, 2011 at 10:12 AM,  <will@ccs.neu.edu> wrote:
> 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@scheme-reports.org
> http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports
>

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