Hacker News Reader

Comment by tmd | Hacker News Reader

It responds "No" to (10000000000000000, 10000000000000001, 10000000000000002) so the rule is not so simple after all :)

Responds "Yes" to

  9007199254740990, 9007199254740991, 9007199254740992

but "No" to

  9007199254740991, 9007199254740992, 9007199254740993

Presumably this is due to how Javascript handles integers, i.e. it uses the integer part of a float64, to wit

  > parseInt('9007199254740992')
  9007199254740992
  > parseInt('9007199254740993')
  9007199254740992

Edit: I think this is the code that actually reads the numbers the user enters, see [0]

  function l(){
      var a=h.exec(m[1]),f=null,g=null,n=null;
      return a&&(null!==a[1]&&a[1]&&(f=parseInt(a[1],10)),
          null!==a[2]&&a[2]&&(g=parseInt(a[2],10)),
          null!==a[3]&&a[3]&&(n=parseInt(a[3],10))),
      new e(f,g,n)
  }

Edit(2): Actually, I'm not so sure that's the correct code at all. They NYT game is capable of parsing floats correctly (e.g. it accepts 1.1, 1.2, 1.3 as a "Yes") so it's not just using parseInt.

[0] http://a1.nyt.com/assets/interactive/20150612-151638/js/foun...

you broke it.

yeah alright.. i think someone didn't actually get the point of the article hehe

The actual code seems to be from here [0]

on line 588 is the comparison

    var rightWrong = (inputData[0] < inputData[1]) & (inputData[1] < inputData[2]) ? right : wrong;

With a variable declaration on line 545 being

    var inputData = [NaN, NaN, NaN],
        revealed = false,
        right = "<p class = 'g-answer g-yes'>Yes!</p>",
        wrong = "<p class = 'g-answer g-no'>No.</p>";

And `inputData` is changed on text input on line 662

    $("#g-input input").each(function(i) {
        var val = $(this).val();
        inputData[i] = $.isNumeric(val) ? Number(val) : NaN;
    });

It uses the `Number()` function to convert from the input text to an actual number, so it can convert any number format defined by ES5[1] or ES6[2]. So in ES6 you can use binary (0b, 0B) and octal (0o, 0O) formatting along with exponential (1e-2) and hex (0x, 0X). Binary and octal works for me currently on Chrome 43 OS X.

[0] http://graphics8.nytimes.com/newsgraphics/2015/06/16/puzzle/...

[1] http://www.ecma-international.org/ecma-262/5.1/#sec-9.3.1

[2] http://www.ecma-international.org/ecma-262/6.0/#sec-7.1.3.1

Further subtleties:

* The number may have optional sign and digits after a decimal point, and may use exponential notation. Example: (-1.2e1, .0E+0, 1.e-3) => "Yes". As seen in the second and third number here, there may be no digits before or after the decimal point, but both at the same time (i.e., ".0" and "0." parse but not ".").

* If the number begins with "0x" or "0X" it is read in hexadecimal, where the digits a-f may be in either case. Hexadecimal notation must not be accompanied by decimal point, sign, or exponential notation.

* No whitespace is permitted within the numeral, even between the sign and the digits as in "+ 11", but both tabs and spaces may be used before and after the numeral without changing its value. In particular, by using a input of the form "1 " it is possible to make rectangular display empty while still parsing it as number. Note that pressing "Check" leads to the numbers being displayed in the rectangle in exactly the same way as they were displayed in the text box, which may depend on the position of the cursor in the text box.

ETA: Also, you mentioned rounding, but there is also exponent overflow and underflow. The application refuses to parse numbers greater or equal to 1.7976932e308. It parses arbitrary negative exponents fine, but it does not recognize that 1e-324 is greater than 0.

A test engineer walks into a bar. He orders a beer. He orders two beers. He orders 999999999 beers. He orders 1.00001 beers. He orders -42 beers. He orders 1048576 beers...

Yes, but did he think to order NaN beers?

Only on hackernews :O

Good old IEEE 64bit floating point numbers =)

That also means that for(i=0;i<j;++i){} doesn't necessarily terminate for an arbitrary j smaller than infinity, which I find hilarious.

I'd prefer an example along the lines of:

    for(i = j; i < j + 2; i++) {}

With your example it's easy to lose the distinction between "would eventually terminate if you had a fast computer and a lot of time" and "never terminates even in theory." Here, it definitely looks like it should always run two iterations to matter what the numbers are (as long as they're finite), but it doesn't.

Either way, though, it is definitely hilarious!

Thanks to undefined behaviour, C compilers can assume that you get exactly two iterations for this kind of loop on ints.

It terminates for an arbitrary j smaller than 2^53, which is enough for most people.

Any idea why? Could it be an error from the input being too large? Or is there some other magic at work here...

Nedit: One of the other responses nailed it. IEEE standards on 64 bit fp ops

Reply on news.ycombinator.com