If it has no meaning, then the comparison should have an unspecified result, not true. Otherwise it has a meaning: the meaning of producing true! However, it is a poorly considered meaning which requires a thing to be different from itself.
Since NaN values are valid representations which play a role in the system, and can be used in operations (such as comparing a NaN to a number, which is false), each of them must compare equal to itself.
If the bits on the left are the same as the bits on the right, the comparison is true. Distinct NaN bit patterns are unequal. Simple as that.
Whatever I would do, I would make sure that a comparison observes the Law of Identity.
(I'd rather not have Inf and NaN at all; operations should just generate an exception if they can't come up with a number.)
You have a fairly complex logic being stuffed into a binary operation — NaN == NaN and NaN != NaN are both irresponsible. The same with comparing to INF. The correct answer is that boolean operations don’t successfully represent the possibilities, and shouldn’t be offered in the first place.
That is a valid view. NaN is supposed to propagate an error value, and that concept should continue through Boolean expressions. So that is to say, there has to be a NaT (not a truth) value which results instead of true or false, if a NaN is involved in a relational expression.
Problem is, that is impractical. Programming languages tend to have two-valued Boolen baked into their DNA; it's implicit in if/then/else conditionals which will have to treat NaT as false --- back to square one.
Programming languages with two-valued Booleans are not going to accommodate such a thing (it is not as easy to sneak in as NaN into floating-point). Even if they were to, programmers are going to be reluctant to turn every if/then situation into a three-way switch.
Besides the case of floating-point numbers with NaNs there are many other cases of partial order relations.
The problem is that most people know how to handle only total order relations, for which only 6 operations with Boolean results can be defined (equal and not-equal, less and greater-or-equal, greater and less-or-equal).
While it is possible to handle partial orders using ternary logic, it is easier to handle them with operations with Boolean results, so this is what all programming languages either provide or they should provide.
The difference is that for partial orders you no longer have only 6 operations with Boolean results (3 plus their negations), but you have 14 operations (7 + their negations).
One operation pair is ordered / unordered (ordered means either equal or less or greater).
The other 6 pairs correspond to the 6 well known relational operators from the total order, which now no longer are each other's negation, together with their 6 negations, which now include the possibility that the 2 operands are unordered.
For example, corresponding to the negation pair less and greater-or-equal from the total order, for a partial order there are 2 negation pairs, less and not-less (i.e. greater, equal or unordered) and greater-or-equal and neither-greater-nor-equal (i.e. less-or-unordered).
In the education of the programmers there should be more stress on the possible relational operators for partial order relations, because they appear in many situations, both for FP computations and for databases, and handling partial orders is only slightly more complex than handling total orders, but many people are not accustomed to this.
Read that Chesterton quote somebody posted above. It sounds like you need to study the standard a bit more, because you don’t seem to understand why NaNs are the way they are. You’re arguing from principles that don’t apply.
I don't know enough to say; all I remember from the few interactions I've had with SQL over my long programming career is that it's intellectually unsavory as a whole.
You must like dividing by zero and never knowing about it. There's a reason why NaN blows things up. It's by design so that math errors don't propagate everywhere.
Comments
What would you do? The comparison has no meaning if NaN.
If it has no meaning, then the comparison should have an unspecified result, not true. Otherwise it has a meaning: the meaning of producing true! However, it is a poorly considered meaning which requires a thing to be different from itself.
Since NaN values are valid representations which play a role in the system, and can be used in operations (such as comparing a NaN to a number, which is false), each of them must compare equal to itself.
If the bits on the left are the same as the bits on the right, the comparison is true. Distinct NaN bit patterns are unequal. Simple as that.
Whatever I would do, I would make sure that a comparison observes the Law of Identity.
(I'd rather not have Inf and NaN at all; operations should just generate an exception if they can't come up with a number.)
You have a fairly complex logic being stuffed into a binary operation — NaN == NaN and NaN != NaN are both irresponsible. The same with comparing to INF. The correct answer is that boolean operations don’t successfully represent the possibilities, and shouldn’t be offered in the first place.
It’s the same with NULL in SQL.
That is a valid view. NaN is supposed to propagate an error value, and that concept should continue through Boolean expressions. So that is to say, there has to be a NaT (not a truth) value which results instead of true or false, if a NaN is involved in a relational expression.
Problem is, that is impractical. Programming languages tend to have two-valued Boolen baked into their DNA; it's implicit in if/then/else conditionals which will have to treat NaT as false --- back to square one.
Programming languages with two-valued Booleans are not going to accommodate such a thing (it is not as easy to sneak in as NaN into floating-point). Even if they were to, programmers are going to be reluctant to turn every if/then situation into a three-way switch.
Besides the case of floating-point numbers with NaNs there are many other cases of partial order relations.
The problem is that most people know how to handle only total order relations, for which only 6 operations with Boolean results can be defined (equal and not-equal, less and greater-or-equal, greater and less-or-equal).
While it is possible to handle partial orders using ternary logic, it is easier to handle them with operations with Boolean results, so this is what all programming languages either provide or they should provide.
The difference is that for partial orders you no longer have only 6 operations with Boolean results (3 plus their negations), but you have 14 operations (7 + their negations).
One operation pair is ordered / unordered (ordered means either equal or less or greater).
The other 6 pairs correspond to the 6 well known relational operators from the total order, which now no longer are each other's negation, together with their 6 negations, which now include the possibility that the 2 operands are unordered.
For example, corresponding to the negation pair less and greater-or-equal from the total order, for a partial order there are 2 negation pairs, less and not-less (i.e. greater, equal or unordered) and greater-or-equal and neither-greater-nor-equal (i.e. less-or-unordered).
In the education of the programmers there should be more stress on the possible relational operators for partial order relations, because they appear in many situations, both for FP computations and for databases, and handling partial orders is only slightly more complex than handling total orders, but many people are not accustomed to this.
Do you also think NULL should equal NULL in SQL?
Read that Chesterton quote somebody posted above. It sounds like you need to study the standard a bit more, because you don’t seem to understand why NaNs are the way they are. You’re arguing from principles that don’t apply.
I don't know enough to say; all I remember from the few interactions I've had with SQL over my long programming career is that it's intellectually unsavory as a whole.
I do think NIL should be EQ to NIL in Lisp.
You must like dividing by zero and never knowing about it. There's a reason why NaN blows things up. It's by design so that math errors don't propagate everywhere.
No; I want an exception. The software image dies, unless it's handed.