Birbla

Join the discussion

Write your take first — we'll ask for email only when you're ready to publish.

Sign in
  • Hacker News
  • I get the idea behind NaN != NaN, but has there ever been any instance where this design decision has made practical code better instead of becoming a tripping hazard and requiring extensive special casing?

    I'm also not a fan of the other property that NaN evaluates to false for all three of <, > and =, even though I don't have a good idea what to do otherwise.

    I think as programmers, we usually assume that "not (a > b)" implies "a <= b" and vice-versa and often rely on that assumption implicitly. NaN breaks that assumption, which could lead to unexpected behavior.

    Consider something like this (in JS) :

      function make_examples(num_examples) {
    if (num_examples <= 0) {
      throw Error("num_examples must be 1 or more");
    }
    const examples = [];
    for (let i = 0; i < num_examples; i++) {
      examples.push(make_example(i));
    }
    // we assume that num_examples >= 1 here, so the loop ran at least once and the array cannot be empty.
    postprocess_first_example(examples[0]); // <-- (!)
    return examples;
  }
    If somehow num_examples were NaN, the (!) line would fail unexpectedly because the array would be empty.
    by xg15
  • NaN comes from parsing results or Infinity occurring in operations. I personally ends up more to use Number.isFinite(), which will be false on both occurrences when I need a real (haha) numeric answer.
    by tuyiown
  • Also remember that NaN is represented in multiple ways bitwise:

    https://en.wikipedia.org/wiki/NaN

    Also you even have different kinds of NaN (signalling vs quiet)

    by nhatcher
  • NaNs aren't always equal to each other in their bit representation either, most of the bits are kept as a "payload" which is not defined in the spec it can be anything. I believe the payload is actually used in V8 to encode more information in NaNs (NaN-boxing).
    by jasonthorsness
  • Shouldn't an operator on incompatible types return undefined? ;)

    Equality on things that it doesn't make sense to compare returning false seems wrong to me. That operation isn't defined to begin with.

    By shipping with undefined, JavaScript could have been there only language whose type system makes sense... alas!

    by andai
  • The D language default initializes floating point values to NaN. AFAIK, D is the only language that does that.

    The rationale is that if the programmer forgets to initialize a float, and it defaults to 0.0, he may never realize that the result of his calculation is in error. But with NaN initialization, the result will be NaN and he'll know to look at the inputs to see what was not initialized.

    It causes some spirited discussion now and then.

    by WalterBright
  • > That’s also the reason NaN !== NaN. If NaN behaved like a number and had a value equal to itself, well, you could accidentally do math with it: NaN / NaN would result in 1,

    So, by that logic, if 0 behaved like a number and had a value equal to itself, well, you could accidentally do math with it: 0 / 0 would result in 1...

    But as it turns out, 0 behaves like a number, has a value equal to itself, you can do math with it, and 0/0 results in NaN.

    by dragonwriter
  • > That’s also the reason NaN !== NaN. If NaN behaved like a number and had a value equal to itself, well, you could accidentally do math with it: NaN / NaN would result in 1, and that would mean that a calculation containing a NaN result could ultimately result in an incorrect number rather than an easily-spotted “hey, something went wrong in here” NaN flag.

    While I'm not really against the concept of NaN not equaling itself, this reasoning makes no sense. Even if the standard was "NaN == NaN evaluates to true" there would be no reason why NaN/Nan should necessarily evaluate to 1.

    by KalMann

Explore Birbla archives