> That doesn't change the fact that in such a system, the NaN type will, by definition, define a comparison operator that always returns false and expose some other means to determine if a value is a NaN.
That's a language design decision. You don't have to define that kind of comparison operator. You certainly don't have to make the standard == behave that way.
> You certainly don't have to make the standard == behave that way.
Is equality an attribute of the operator or an attribute of the type and value? The fact that one defines operators on types—and that things such as how values compare to each other is based on types and their coercion rules when compared (str==num→false, unless you define how a num becomes a str or a str becomes a number, which is type based)—says to me that it's the latter.
Using the same symbol for two arbitrary, unrelated things is confusing for the reader - especially if you're using a symbol and a term that already have a standard mathematical meaning. 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). And this means you can write code that uses that + operator in a generic way and be able to rely on it making sense - e.g. if you write a "sum of a list" function, and then refactor it to sum the lists in parallel, if your refactoring was correct for lists of numbers it will be correct for lists of strings as well.
(If your language doesn't allow polymorphism, you might have to write the same code twice but you'd be able to use the same symbol, which helps a reader understand how it's conceptually the same thing)
"==" 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.
> "==" 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.
That's a language design decision. You don't have to define that kind of comparison operator. You certainly don't have to make the standard == behave that way.