[email protected] 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". [email protected] --Cordwainer Smith, Norstrilia _______________________________________________ Scheme-reports mailing list [email protected] http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports
