The equality operation should only apply its own specific logic to a pair of operands which fail the bitwise test.
(That doesn't mean all bits have to be looked at, like if an object has padding bits that don't contribute to the value.)
In floating-point, like IEE754, a positive and negative zero still compare equal; they failed the bitwise test, so then the numeric logic still concludes they are the same number.
You are asserting that as if it were some kind of law of nature, but I'm afraid that's just your personal misconception. The IEEE754 equality function is defined such that it can sometimes be false when applied to identical operands. There are very good reasons why that is the case, just like there are very good reasons why NULL = NULL is false in SQL.
See upthread: law of identity. That's even higher than nature.
> The IEEE754 equality function is defined such that it can sometimes be false when applied to identical operands.
Cool! So, OK, (1) don't promote that function into the fundamental equality operator of programming languages; put it in a library. (2) provide a real equality in parallel.
I should be able to do things like this:
double x = find_number_in_list(list, number, not_found_nan);
if (x == not_found_nan) { /* wasn't found */ }
We can have all sorts of weird functions whose properties are useful insofar that they remove complexity or verbosity from specific scenarios in which they are used.
For instance, it's useful to have a numeric equality operator which tests that two values are within a small epsilon of each other and reports true. That's not even an equivalence relation though; near(A, B) and near(B, C) does not imply near(A, C).
It would be pretty irresponsible to put this behavior into the principal equality, like the one and only built-in == operator of a language or what have you.
> there are very good reasons why NULL = NULL is false in SQL.
I don't know much about SQL, but I understand why, in a join of two tables based on some field equivalence, you wouldn't want to include the entries where the fields are NULL.
However, there is no conflict here with the Law of Identity.
In a database, a NULL field is an external representation stored in a table. We can define a model of computation whereby when the database record is internalized for processing, each NULL field value maps to a unique object. This is very similar to the concept of an uninterned symbol in Common Lisp:
(eq '#:null '#:null) -> NIL
However, we can retain the idea that if we pull a null value from a specific field from a specific record, that null value is equal to itself. We do not have to throw the Law of Identity under the bus, in other words:
(let ((sym '#:null)) (eq sym sym)) -> T
select * from X where X.Y == X.Y