-----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@scheme-reports.org
http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports