Back

@dseguy Is there a reason for this, or is it a bug?

@ramsey @dseguy I believe that nan is defined to work this way by the IEEE spec for floating point numbers. I have to say that, in my own experience, I've never found a practical situation where this property helped anything in code

@ramsey @dseguy FWIW, I wouldn't be surprised if @wez is right.

JavaScript shouldn't be taken as an example of a good way to do things, as a general rule...

https://www.destroyallsoftware.com/talks/wat

... but it does behave similarly in this particular respect.

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/NaN#testing_against_nan

@elazar @dseguy @wez In another branch of this thread, we discussed how NaN is specific to mathematics and doesn’t make sense when considered outside that context. In maths, NaN doesn’t represent anything, so it can’t be equal even to itself.

Of course, if you only take the meaning of the phrase “not a number,” then in a programming context, things like `"some string" == NaN` and `$someObject == NaN` could be true because they’re not numbers.

@ramsey @elazar @wez So, it makes sense to me, besides the initial surprise when discovering it.

I have encountered situations where ``null !== null``, on the basis that it is not a value, and can't be compared. That would not fit PHP, though.

If any bug there is, I'd say that ``INF === INF`` should not be true (as it is now), as there are different infinities (some are even bigger than others!) I'd expect it to behave like NAN.

INF is used in 10% PHP code, and NAN is 5%.

@dseguy @ramsey @elazar @wez to be pedantic: for most situations PHP arithmetic code is going to be involved with, there aren't really different infinities.

I'm not clear whether INF === INF is going to cause real-world logic errors though.

@dseguy @ramsey @elazar @wez disallowing division by zero solved about 99% of the cases :)