You can *round* 4611686018427388000 to the nearest representable integer in that format, which is 4611686018427387904. But there is no reason to conjure up 4611686018427388000 when converting back to integer. That is just wrong and broken.
-
If you'd like to see the fun floating point bits, if you're trying to learn how floats work, you can do that with Number.prototype.toPrecision, toExponential, toFixed, which omit the logic to put 0's at the end.
My issue is the lack of any evidence that the number is a float; that rounding occurred. JS is in the awkward position of using floats for the use cases of ints. Presumably this drove the decision to have toString output just digits when the float is an exact integer value.
-
-
But then toString goes and *rounds* larger ints - at which point they're not floats trying to be ints any more - yet it still outputs just digits. And that is just confusing and messy.
-
Sure, there are ways to get the full value out. My point here is that the default behavior is unintuitive and misleading in this particular case. Nobody expects an integer to have been rounded. Having to deal with the 53-bit ceiling is bad enough; toString hiding it is worse!
- Show replies
New conversation -
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.