Hector Martin

you think every implementation follows the spec properly? this is web browsers; today doesn't apply to last decade, where the constraints existed

IEEE 754 predates web browsers. It came out in 1985. And besides, IEEE 754 is baked into CPUs anyway, so browsers aren't going to randomly mess it up. The only problem here is JS *lies* when converting to a string.

No other programming language does this. No other programming language takes a floating-point value representing an integer, and, when converting it to a string, says "you know what, I'm going to give you a different integer, without any indication that rounding has occurred".

yeah, i know. i've been dealing with the oddness since the beginning... i'm not trying to defend it, just tried to point you at the 'why'. v8 has bigint now, and so does node 10.4.x afaik, so things are getting better (slowly, very slowly)

Yes, and hilariously, (4611686018427387904).toString() is "4611686018427388000" (the wrong answer), while BigInt(4611686018427388000).toString() is "4611686018427387904" (the right answer) (or it will be once Chrome catches up with the spec, right now it's an error).

try `0x4000000000000000n` ;) ... the 'n' is important atm

Yes, my point is that BigInt's conversion (once relaxed; the standard got changed recently to allow converting floating-point integers >2^53) proves that the real underlying integer behind the float value is 4611686018427387904, not 4611686018427388000.