[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

*To*: scheme-reports@x*Subject*: Re: [Scheme-reports] Proposed language for 'eqv?' applied to inexact real numbers*From*: Ray Dillinger <bear@x>*Date*: Mon, 12 Nov 2012 09:36:37 -0800*In-reply-to*: <87lie6hlxi.fsf@tines.lan>*References*: <87k3tr9azi.fsf@tines.lan> <87y5i7h1wh.fsf@tines.lan> <CA+U71=MviDMYuKEYo5+04rSLOdprpjjXa2Z7-BCN8YS7-j5pAg@mail.gmail.com> <87lie6hlxi.fsf@tines.lan>

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 11/12/2012 07:37 AM, Mark H Weaver wrote (citing Alex Shinn): > The eqv? procedure returns #t if one of the following holds: [...] > * 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. > The problem has to do with NaNs. Since (= obj1 obj2) is needed for > the above condition to apply, and a NaN object is not '=' to > itself, it follows that (let ((x +nan.0)) (eqv? x x)) => > unspecified. The Non-equivalence of NaN under = is misleading and should not be used to justify any other result. To do so is a semantic mistake. Therefore eqv? should return true for (eqv? NaN NaN). NaN is NOT A NUMBER, and the question of its numeric equivalence to anything does not make sense. The question is a category error and therefore both the "true" answer and the "false" answer are meaningless. The broader question of eqv? equivalence on the other hand, does make sense, and can be answered meaningfully. The semantics-wrecking properties of NaNs arise when we forget that numeric equivalence on non-numbers is a category error and use the "false" result of the numeric equivalence predicate as though it were meaningful information. It's easy to see the rationale for a non-true result as "testing numeric equivalence on something that isn't a number is nonsense." But this is an equally strong rationale for a non-false result. If we take the "nonsense" argument that IEEE 754 uses as its rationale for "not true" seriously, then inescapably it is also an argument in favor of "not false." (= NaN NaN) ==> type error, NaN means NOT A NUMBER rather than (= NaN NaN) ==> false. If we interpret "false" as meaningful information in this case, we are conflating "false" (things are indeed unequal) with "falsum", the notion that the question of numeric equality does not even make sense. "Falsum", if we modeled it in our language, would be Not-A-Boolean in the same way that NaN is Not-A-Number. The point is that we're using NaN as a non-signalling type error. We have numeric operations which produce things that aren't numbers, and doing numeric operations on *those* things is a type error. But we don't want to halt the computation and signal, nor put in checks that will slow it down and obscure the code, so we just silently propagate NaN through more numeric operations to the edges of the numeric code where the error (now represented as a value) will be detected in another way. Or at least that's the idea behind the design. But we fail to follow through on that design when we let the equivalence predicate swallow the error and convert it to a "false" which we accept as a meaningful value rather than an indication of an error. That is a semantic mistake. This "false" is in fact meaningless -- just as meaningless as "true" would be in the same circumstance. We must not use it to decide further semantics. Bear -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJQoTOlAAoJEAOzWkqOibfNG4AH/jrOIEk4jsZhEyWYiGYexV5d +eQXXTxWtGa6eQ8p9XQkUSs8iMptMzzRSfLEFjWs4s97E5tuD3TLM+iFXlnZw2hi aZgAScHfKEEDZroJy/ioBMyQZWQjZqTSpnZ1TjjYbuK7n6Ws12lyd0YJ0YEK3eog yYmLuXbwQfa8wQA7pWqE4K60DhKSK+JkQAhHd9d2tXhGCLEY/SfQ8cI7PMNn7n1B Wr3YxXulMkvt5MnuIX0kml5Q3O/F/m61u5LlHpF5sI04SDKkOr2dXlySLS4nF9Ky vyw2PutTCg3LECm8jDG/IFtWX6kYSOKNT5b5iHMeErboQgyEtbZX+XzFmjNEpSY= =HGfm -----END PGP SIGNATURE----- _______________________________________________ Scheme-reports mailing list Scheme-reports@x http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports

**Follow-Ups**:**Re: [Scheme-reports] Proposed language for 'eqv?' applied to inexact real numbers***From:*John Cowan <cowan@x>

**References**:**[Scheme-reports] Formal Comment: R7RS 'eqv?' cannot be used for reliable memoization***From:*Mark H Weaver <mhw@x>

**[Scheme-reports] Proposed language for 'eqv?' applied to inexact real numbers***From:*Mark H Weaver <mhw@x>

**Re: [Scheme-reports] Proposed language for 'eqv?' applied to inexact real numbers***From:*Noah Lavine <noah.b.lavine@x>

**Re: [Scheme-reports] Proposed language for 'eqv?' applied to inexact real numbers***From:*Mark H Weaver <mhw@x>

- Prev by Date:
**Re: [Scheme-reports] Proposed language for 'eqv?' applied to inexact real numbers** - Next by Date:
**Re: [Scheme-reports] Proposed language for 'eqv?' applied to inexact real numbers** - Previous by thread:
**Re: [Scheme-reports] Proposed language for 'eqv?' applied to inexact real numbers** - Next by thread:
**Re: [Scheme-reports] Proposed language for 'eqv?' applied to inexact real numbers** - Index(es):