really? I drastically prefer bytearray. In all fairness my experience with JS dev is limited to exploitation of webkit, meaning I'm probably playing with the absolute nastiest of edge cases, but like... I really like python a lot more? It feels cleaner to me in a lot of ways
-
I think you’re confused about what double-precision floating-point means. See: https://tc39.github.io/ecma262/#sec-ecmascript-language-types-number-type … https://en.wikipedia.org/wiki/Double-precision_floating-point_format#IEEE_754_double-precision_binary_floating-point_format:_binary64 … https://developers.google.com/web/updates/2018/05/bigint … https://mathiasbynens.be/demo/integer-range … For integers, JavaScript uses 53 bits to store the digits and + 1 for the sign.
I think you're confused about what "integer" means. The 64-bit IEEE754 floating point value represented by the (big-endian) bytes 43d0000000000000 *represents* the int 4611686018427387904. It does *not* represent the int 4611686018427388000. The latter is not representable.
-
-
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.
-
Yes, the ECMAScript spec says toString must be implemented in this (broken) way. This is insane, and no other sensible language does this. It is misleading and wrong. https://tc39.github.io/ecma262/#sec-tostring-applied-to-the-number-type …
- 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.