> "==" for two different types won't do exactly the same thing, but it should always be a well-behaved "equals" operation that satisfies the usual expectations that a reader would have. That usually includes that any value is equal to itself.
NaN is not the same kind of value that any number, say 3.14, is. I would expect that "the reader" with "usual expectations" would be familiar with floating point operations, how NaN works when it comes to equality is well defined, as well defined as equality over integers.
I'm not sure what point you're trying to make. That "equality" as embodied in the operator "=="? But further up the thread I talk about how equality, and other operators, is something that is defined on/by the types, you admit as much when you say:
> str + str for concatenation might seem unrelated to num + num, but it's a valid "+" in the standard mathematical sense of being a valid monoid operation (i.e. it's associative).
How operators work is an attribute of the types the operators work on. str defines the + operator to mean concatenation, which is entirely different from the meaning of the + operator when applied to integers, or what should be expected to happen when the LHS and the RHS of the binary + operator are of different types (some choose to do fail without explicit conversions, others choose to implicitly convert or promote).
isNaN is used to determine if the bitpattern in a floating point value is NaN because equality on the bitpattern that is floating point is defined very specifically for those bitpatterns. The same could be said for a hypothetical isPi function over the floating point domain, which could be defined to return true for any value that approximates π, which makes sense because the exact value of π can not be represented in binary or in decimal. Being an irrational number, equality wouldn't work on a floating point representation/approximation of π either, so a separate operator (operator is just another name for function) would be necessary in order to determine if a given value was Pi-approximate.
> I would expect that "the reader" with "usual expectations" would be familiar with floating point operations
Why? Why should every single programmer be expected to be an expert in this particular obscure datatype, to the point that it's ok for it to break all the normal rules that normal datatypes follow?
> How operators work is an attribute of the types the operators work on. str defines the + operator to mean concatenation, which is entirely different from the meaning of the + operator when applied to integers
It's not "entirely different". It conforms to the normal mathematical definition of + and has the properties that a reader would expect + to have (e.g. associativity). Defining to e.g. search strings would be bad and confusing.
NaN is not the same kind of value that any number, say 3.14, is. I would expect that "the reader" with "usual expectations" would be familiar with floating point operations, how NaN works when it comes to equality is well defined, as well defined as equality over integers.
I'm not sure what point you're trying to make. That "equality" as embodied in the operator "=="? But further up the thread I talk about how equality, and other operators, is something that is defined on/by the types, you admit as much when you say:
> str + str for concatenation might seem unrelated to num + num, but it's a valid "+" in the standard mathematical sense of being a valid monoid operation (i.e. it's associative).
How operators work is an attribute of the types the operators work on. str defines the + operator to mean concatenation, which is entirely different from the meaning of the + operator when applied to integers, or what should be expected to happen when the LHS and the RHS of the binary + operator are of different types (some choose to do fail without explicit conversions, others choose to implicitly convert or promote).
isNaN is used to determine if the bitpattern in a floating point value is NaN because equality on the bitpattern that is floating point is defined very specifically for those bitpatterns. The same could be said for a hypothetical isPi function over the floating point domain, which could be defined to return true for any value that approximates π, which makes sense because the exact value of π can not be represented in binary or in decimal. Being an irrational number, equality wouldn't work on a floating point representation/approximation of π either, so a separate operator (operator is just another name for function) would be necessary in order to determine if a given value was Pi-approximate.