[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: John Cowan <cowan@x>
- Date: Thu, 29 Sep 2011 19:36:05 -0400
- Cc: scheme-reports@x
- In-reply-to: <18167054.1435761317335487249.JavaMail.root@zimbra>
- References: <15162962.1435681317334699236.JavaMail.root@zimbra> <18167054.1435761317335487249.JavaMail.root@zimbra>
will@x scripsit:
> And I concede that I was wrong to say that "same*" is the R6RS
> semantics.
Okay then, let's see if we agree on the facts. Let nan and nan2 contain
NaNs, possibly but not necessarily with different bit patterns implying
different origins.
In all cases, (eqv? nan x) where x is not a NaN required to return #f,
assuming that (= nan x) returns #f for any x even in R5RS.
The R5RS semantics requires (eqv? nan nan) and (eqv? nan nan2) to return
#f (though many implementations violate this).
The R6RS semantics allows (eqv? nan nan) and (eqv? nan nan2) to return
either #t or #f.
The "same" semantics requires (eqv? nan nan) and (eqv? nan nan2) to
return #t.
The "same*" semantics requires (eqv? nan nan) to return #t and allows
(eqv? nan nan2) to return either #t or #f.
The "different" semantics is the same as the R5RS semantics.
> The important point, however, is that the R6RS semantics allows the
> "same*" semantics, but the "same" semantics described in the ballot
> question does not allow the "same*" semantics.
I agree.
> Since the "same*" semantics is the most reasonable semantics for an
> implementation, it would be better to adopt the R6RS semantics than
> the "same" semantics.
I'm not sure I believe that "same*" is so reasonable. It allows EQV? to
make distinctions that other procedures cannot make.
> The identity of indiscernibles is valid only in certain contexts, such
> as final algebras. No extant standard for Scheme requires all NaNs to
> be collapsed onto a single value. If the R7RS were to require that,
> every arithmetic operation on IEEE floating point numbers would have
> to be followed by a NaN test so any NaN result could be converted to
> the canonical value.
I am saying that the multiple *representations* for +nan.0 constitute
a single *value* even in R6RS, for there is no procedure that can
portably distinguish between them. That does not mean that with the
"same" semantics the representations need to be coerced to a single
representation, merely that EQV? refuse to distinguish them. However,
if this is confusing I am willing to drop all talk of a single value.
> Although none of Scheme's standard arithmetic procedures are
> *required* to produce different results when applied to NaNs of
> different bit patterns, it's easy to show that some of Scheme's
> standard arithmetic procedures are *allowed* to produce different
> results when applied to NaNs of different patterns [...].
Can you exemplify this? Your example uses eqv?, which is petitio
principii as well as not being an *arithmetic* procedure according to
the meaning of the Act.
> > 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.
>
> Then we'll have to argue about this for a while. I'm not on the WG1
> committee, so I don't get a vote. Arguing is the best I can do.
Okay, let's go on talking.
> The R7RS should not overrule the IEEE standards just to make all of
> Scheme's inexact arithmetic run slower.
The "same" semantics only requires EQV? to run slower (because it must
treat NaNs specially and can't do a bit-for-bit comparison, as it can
for other flonums).
--
John Cowan cowan@x http://ccil.org/~cowan
If I have seen farther than others, it is because I was standing on
the shoulders of giants.
--Isaac Newton
_______________________________________________
Scheme-reports mailing list
Scheme-reports@x
http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports