[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Scheme-reports] ballot question #229: EQV? and NaN
- To: will@x
- Subject: Re: [Scheme-reports] ballot question #229: EQV? and NaN
- From: Alex Shinn <alexshinn@x>
- Date: Thu, 29 Sep 2011 17:54:49 +0900
- Cc: scheme-reports@x
- In-reply-to: <7338873.1419301317258726937.JavaMail.root@zimbra>
- References: <7407593.1419281317258624672.JavaMail.root@zimbra> <7338873.1419301317258726937.JavaMail.root@zimbra>
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.
On Thu, Sep 29, 2011 at 10:12 AM, <will@x> 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)
>> (eqv? nan1 nan1)
>> (eqv? nan2 nan2)
>> (eqv? nan0 nan1)
>> (eqv? nan0 nan2)
>> (eqv? nan1 nan2)
>> (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.
> Scheme-reports mailing list
Scheme-reports mailing list