Demystifying NaN for the Working Programmer
lucidchart.com
Demystifying NaN for the Working Programmer
1–10 of 38 posts
Re: Demystifying NaN for the Working Programmer
#2Excellent article, this helped me understand the issues working with floating numbers. I work with them quite a lot when developing business logic and often times NaN can be a pain. Understanding why helps a lot.
Re: Demystifying NaN for the Working Programmer
#3I did a code assignment for a potential JavaScript heavy job in 2014, for some reason I think isNaN was part of the language then because I have a memory deciding not to use it (but could be misremembering), at any rate I did Number(x) !== Number(x) at some point.
In the meeting when they went over the code the guy who did it said we were wondering why you did this? So I had to explain NaN to him. He really did not know it existed. At any rate I thought this is a weird thing not to know anything at all about.
Re: Demystifying NaN for the Working Programmer
#4Imagine doing if(x) ..., where x can be NaN. Shouldn't that throw an exception in most cases? Why are our compilers not doing it that way?
Re: Demystifying NaN for the Working Programmer
#5I love NaNs, especially their "infectious" quality. Initializing float variable to NaNs before first assignment can make a lot of errors immediately obvious. I wish there were a NaN for integers.
Re: Demystifying NaN for the Working Programmer
#6I love NaNs, especially their "infectious" quality. Initializing float variable to NaNs before first assignment can make a lot of errors immediately obvious. I wish there were a NaN for integers.
Don’t initialize them and turn on UBSan :)
Re: Demystifying NaN for the Working Programmer
#7> The only reliable way to test for NaN is to use a language-dependent built-in function; the expression a === NaN is always false
Well, you test for it by comparing the value against itself and seeing if that returns false.
(There’s also a bit of confusion on by value vs. by reference comparison and the actual bit value on a NaN, which isn’t quite right.)
Re: Demystifying NaN for the Working Programmer
#8> The only reliable way to test for NaN is to use a language-dependent built-in function; the expression a === NaN is always false Well, you test for it by comparing the value against itself and seeing if that returns false. (There’s also a bit of confusion on by value vs. by reference comparison and the actual bit value on a NaN, which isn’t quite right.)
Signaling NaNs raise exceptions in some operations. Is comparison one of these?
Re: Demystifying NaN for the Working Programmer
#9> The only reliable way to test for NaN is to use a language-dependent built-in function; the expression a === NaN is always false Well, you test for it by comparing the value against itself and seeing if that returns false. (There’s also a bit of confusion on by value vs. by reference comparison and the actual bit value on a NaN, which isn’t quite right.)
Signaling NaNs raise exceptions in some operations. Is comparison one of these?
They “raise exceptions” in the IEEE 754 sense, which is not at all the same thing as what most programming languages mean by “raise exception”. It means that they set a sticky flag in a register that may be queried at a later point, not that program control flow is redirected.
Re: Demystifying NaN for the Working Programmer
#10Imagine doing if(x) ..., where x can be NaN. Shouldn't that throw an exception in most cases? Why are our compilers not doing it that way?
Should it? It isn't obvious to me at all that throwing an exception in this case is the best behaviour. Throwing an exception when testing a value for 'truthiness' is extremely surprising.
On the other hand, I would strongly discourage 'if(x)' where x is a float that may be NaN purely because the 'correct' behaviour here isn't clear to me.