NaN can happen for a lot of different reasons. You might have divided by zero because your code is broken, or you might have divided by epsilon because your algorithm isn't stable on this problem. [1]

This test checks to make sure none of {f, g, x, y, intermediate_values} were ever NaN, wihtout having to test each one every step of the way.

    if (  f(x) == g(y)  )

[1] I'm fuzzy on the details. Corrections solicited.

Actually most of these posts seem to be the author misunderstanding floating point numbers. Perhaps he should learn what he's doing before he blames the language.

If (NaN == NaN) == false, and (NaN === NaN) == false, how would you implement an isNaN() function? If your answer is 'depend on the VM', I find that a bit strange.

No, it isn't, absolutely.

`===` means that javascript does a normal equality test, whether it be string comparison or numerical comparison, but without any type conversion. It means that while `"3" == 3` is `true` when you execute `"3" === 3"` it is false.

Given two `NaN`s, it would see they're both floats, do a floating point comparison, and return `false`. As it should.

If the values are not equal, how can both the values and types be?

Looking at the ECMAScript 5 standard even if you take out the explicit handling of NaN in the === (Strict Equality) definition it should still evaluate to false since the next subrule compares the numeric value.

4.If Type(x) is Number, then a.If x is NaN, return false. b.If y is NaN, return false. c.If x is the same Number value as y, return true.

0.1 + 0.2 === 0.3 // false

I'd say that whoever posted that needs a lesson in how floating point works.

There's no language that lets you do real-world work with numbers like sqrt(2) or PI without understanding precision and representation to some degree.

  >>> from decimal import *
  >>> Decimal('0.3') == Decimal('0.1') + Decimal('0.2')
  True
  >>> Decimal('NaN') == Decimal('NaN')
  False
  >>>

However, your code example makes the excellent point that python has such a library available, whereas Javascript does not. At least, not as easily as an import.

I can see that some of the design decisions in IEEE-754, like NaN not beeing equal to NaN might seem unintuitive, but it has nothing to do with JavaScript - the standard is implemented by numerous languages and hardware.

That large numbers are rounded to a limited precision should not even be wtf if you think about it for a moment. Otherwise a single use of PI would fill up all the computer memory.

    >>> x = new Boolean;
    false
    >>> b = (x || !x);
    false
    >>> Boolean(b == false) && Boolean(x == false) && Boolean(b) && Boolean(x)
    true

Didn't understand this one at first, but I guess it is easy: first x becomes the reverse function of arrays, then it is called with this === window. So it amounts to window.reverse(). Just looked it up, and reverse() works in place, so window.reverse() === window - although it is potentially different from before.

So just saying 'this' in an arbitrary function has the same effect.

    * (= (+ 0.1 0.2) 0.3)
    T
    * (type-of 0.1)
    SINGLE-FLOAT
    * (= 0.3d0 (+ 0.1d0 0.2d0))
    NIL
    * (type-of 0.1d0)
    DOUBLE-FLOAT

  Prelude> (0.1 + 0.2) == 0.3
  False
  Prelude Ratio> 1 % 10 + 2 % 10 == 3 % 10
  True

    ghci> 0.1 + 0.2 == (0.3 :: Ratio Int)
    True

The question of which Simon is left as an exercise to the reader.

0.1 + 0.2 == 0.3 => false

According to "The Ruby Programming Language", all languages that use IEEE-754 floating-point numbers have this problem.

In Ruby you can get around this by using BigDecimal.

>> require 'bigdecimal'

=> true

>> require 'bigdecimal/util'

=> true

>> 0.1.to_d + 0.2.to_d == 0.3.to_d

=> true

  >>> decimal.Decimal(".2") + decimal.Decimal(".1") == decimal.Decimal(".3")
  True
  >>> .2 + .1 == .3
  False

>JavaScript interpreter checks all variable declarations in scope before execution.

This is another way of saying that all variable declarations are scoped at the function level, not the individual block level. This is why generating closures in a loop is broken in javascript (Although in just about every other language as well, closures in a loop give surprising results at first - including, I think, arc?)

To get a new scope, you have to use the anonymous function trick:

    (function(){
       var x;//new scope
       ...
      })()

<shameless plug>

I feel compelled to mention my WTF JavaScript library, even though it is something completely different: http://github.com/techiferous/wtf-js/blob/master/javascripts...

It's a library for dealing with World Time Format conversions: http://worldtimeformat.com/

</shameless plug>

Some guy registered WTFPHP.com on 2010/02/12

Say for example Lua (by default) is configured to use only double. It can be configured to use single-float, or even integer - but only one numeric type.

Edit: I get it now. null coverts to 0