Two Case Studies of NaN

https://sebsite.pw/w/20260709-nan.html

by ryantsuji • 13 days ago

32 18 13 days ago

whatever1• 9 days ago

Just store what you mean to store for gods sake. We have been fighting with over-designed bs for decades.

Zero is not absence of a value. It has a value, it happens to be 0. Same for undefined/infinity. They exist.

Let the hardware engineers figure out an efficient way to deal with it. If it costs more, well if we add up all of the costs of bugs due to zero/null conversions, maybe it was worth it.

bazoom42• 9 days ago

This article is not about null but about NaN, a special case floating-point value which is the result of diving by zero.

aragilar3• 9 days ago

Specifically, 0/0 (or inf/inf), not any division by 0.

fragmede• 9 days ago

Wat.

I wish there were a recent remake of it.

aragilar3• 9 days ago

Of what, IEEE-754? Given how poorly most languages implement it (and how many shortcuts are taken in the same of speed), I'm not sure IEEE-754 is the problem.

johnsonjo• 9 days ago

Other than the IEE-754 he might mean the Wat talk [1] by Gary Bernhardt which is kind of famous for poking fun at JavaScript (and it's unpredictability with things like NaN. As a JS developer myself I find it hilarious.) Though I don't know why it would need to be remade he at least referenced the talk, it seems, with the word Wat, so it's worth mentioning at least I guess

[1] https://www.destroyallsoftware.com/talks/wat

t-32• 8 days ago

I believe the other poster is correct, that OP is referencing the video "Wat" (https://www.destroyallsoftware.com/talks/wat), but I think that if most implementations of a standard are poor, the standard is probably the problem. It's likely to be either unclear or too complicated.

ColinWright• 9 days ago

adrian_b4• 8 days ago

Equality comparison should be reflexive

Equality comparison must be reflexive for things on which it is defined.

It is wrong to say that NaN is not equal to Nan (because a NaN is neither equal nor not equal with a NaN).

When the invalid operation exception is disabled, because the programmer is too lazy to write a SIGFPE handler or for whatever other mechanism is provided by the operating system to report hardware exceptions, then the set of floating-point numbers is extended with NaNs and the resulting extended set is no longer a totally-ordered set, but only a set on which a partial order is defined.

While floating-point number with NaNs are the best known because they are standardized, there are a lot of real sets that are best modeled as partially-ordered sets, so programming languages should have supported this and programmers should have been taught that partial order relations are something normal and natural, not something weird.

In any partially-ordered set there are elements like the NaNs, on which the relations of order and of equality may be undefined.

Thus NaN is neither equal nor not equal with NaN, but this relationship is undefined.

While for totally-ordered sets 6 relational operators are sufficient, for partially-ordered sets 14 relational operators are necessary.

When the 6 ALGOL relational operators (inherited by all later programming languages) are extended to 14, 6 new operators are provided by the negation of the 6 ALGOL operators, because in a partially-ordered set none of the 6 negations is equivalent with one of the 6 standard operators (like it happens in totally-ordered sets, where e.g. "not less" is the same as "greater or equal"). (In this statement, I considered among the 6 standard operators "less or greater", like in BASIC or SQL "<>", instead of "not equal", like in C "!=".)

The remaining 2 extra relational operators are "less or equal or greater", which could be written "<=>" or ">=<", which may be true only when no operand is a NaN, and its negation, which is equivalent with "one of the operands is a NaN".

Two Case Studies of NaN

Related Stories