Because the designer is sane, and understands that A is A, no matter what A is:
In that case, making (NaN == NaN) == false also defeats it. false isn't NaN either. If true or false propagates out of a function whose inputs are NaN, NaN has failed to propagate.
With that logic, you could say making (1 == 1) == true is wrong, because 1 isn't true.
> If true or false propagates out of a function whose inputs are NaN, NaN has failed to propagate.
He meant Nan propagates through calculation operation, not comparison operation. As in, result of calculating Nan + 1 is NaN.
So if you have "A = NaN" and "B = A + 1", you have the situation that both A and B is NaN but A does not equal B.
1 == 1 isn't erroneous. Producing a boolean is the type of the operation: number x number -> bool.
(bool's domain could be extended with additional "nonbool" values, which are produced if some of the operands to a numeric comparison are not numbers.)
> calculation operation, not comparison operation
What's the difference? It's all computation. The comparison calculates a boolean result.
> As in, result of calculating Nan + 1 is NaN.
No it isn't. Proof:
NaN + 1 == NaN // yields false
What would make sense would be to allocate a new NaN, so that it is legitimate that NaN + 1 != NaN. Neither side is a number, but the express different, individual ways of not being a number through their different identities. And the "isnan(X)" predicate tests whether X is an element of the set of all NaNs.
If that's not palatable, throw exceptions: don't allow NaN + 1 (why allow addition on "not a number"? Why even allow "not a number" to be stored into a variable of number type, in a static language?)
#include <math.h>
#include <stdio.h>
void main()
{
float x = NAN;
float y = NAN;
printf("x == y is %d\n", (x == y) ? 1 : 0);which should print "x == y is 0".
Also, NAN is similar concept to NULL in databases (pretty much "unknown value") and that also does not believe (NULL == NULL).
What language is this?
"In a freestanding environment (in which C program execution may take place without any benefit of an operating system), the name and type of the function called at program startup are implementation-defined."
So, there, the entry point could have prototype
void main();
Well, if you don't have an OS, a lot of things change.
My question comes from all of the C-like Algol-like languages which look like C but... aren't C. You know, like how Java/C# isn't technically one language, but two, for legal reasons.
It is valid ISO C syntax in any environment, which has no meaning according to ISO C.
To have meaning in a hosted environment, the implementation must supply one by accepting "void main" as a startup function in addition to the required forms.
In a freestanding environment, for the program to have meaning, the freestanding implementation must ... supply one by accepting "void main" as a startup function as one of its implementation-defined startup function forms.
It's the same thing: the program is not defined by ISO C, but implementations can give it a local definition of meaning.
If both kinds of implementations support "void main(void)" as an extension, they have to documented it, because an implementation must document all extensions. I'm looking at C99, section 4:
An implementation shall be accompanied by a document that defines all implementationdefined and locale-specific characteristics and all extensions.
So, if "void main(void)" is officially accepted by a freestanding implementation, that means it is one of the implementation-defined startup function forms, and must be documented.
If "void main(void)" is officially accepted by a hosted implementation, it constitutes an extension and must be documented.
Basically, the status of void main appears identical, whether hosted or not, with regard to the definedness of behavior (as far as ISO C is concerned), and the requirement for documentation if it is supported.
#include <math.h>
#include <string.h>
#include <stdio.h>
int main()
{
float x = NAN;
float y = NAN;
printf("x == y is %d\n", (x == y) ? 1 : 0);
printf("memcmp(&x, &y, ...) is %d\n",
memcmp(&x, &y, sizeof x));
return 0;
}
x == y is 0
memcmp(&x, &y, ...) is 0
In fact, even x == x will fail. Direct violation of "A is A".
> NAN is similar concept to NULL in databases
But not similar in concept to NULL in C, where NULL == NULL.
The idea of NaN is that it represents an unknown value, because it essentially says "we don't really know what the result is, but it surely is not a number". And if you have two unknown values, you can hardly check they are equal.
That's why NaN is similar to NULL in SQL, because the concept is basically the same. The difference of course is that C does not have NaN for all the other data types, so it's impossible to say (NaN == NaN) is unknown, because bool, char (or whatever type you use for true/false) does not have the equivalent for NaN. So the next sane option is "false".
The fact that the representation for NaN is the same (so memcmp of two NaN values) is a completely different thing.
If you want two instances of unknown not to be equal, then you can arrange that by actually instantiating different objects with a different identity to represent these unknowns (and print them differently to make it clear: NaN0, NaN1, ... or whatever.
(Yet, if one instance of those objects is propagated into two variables, those variables should still compare equal: NaN0 != NaN1, but NaN0 == NaN0.)
> The fact that the representation for NaN is the same (so memcmp of two NaN values) is a completely different thing.
It tells us it's the same object. In fact, if x is NaN, even x == x fails, and then we have do not even have two bit patterns to compare: it's just one bit pattern. One object at one address, not equal to itself.
In other words, this is garbage that violates "A is A": an object is not itself.
This is the work of imbeciles who chose to be ignorant of the philosophical underpinnings of what they are doing.
That some features of SQL were produced by similar such is neither here nor there.
Really, the answer for any comparison to NaN shouldn't be true or false, it should be something like NaB, Not A Boolean. This is basically what R does:
> 1 == 1 [1] TRUE > NaN == NaN [1] NA
But the major disadvantage of that is that a boolean now has 3 possible states, so it can't be represented in one bit.