To clarify, the "you can still add one to them" is probably the most important part in that definition, given your question.
> Anyway, this definition departs from similar definitions in other languages and AFAICT, existing JavaScript implementations have no problems using 2^53 as an integer. 2^53 can be represented just fine, but `2**53 + 1 === 2**53` is `true`, so adding one to it does not actually increment the value, meaning it does not satisfy the definition of `SAFE` in this context. I think the best source of truth is likely the spec: https://www.ecma-international.org/ecma-262/8.0/#sec-number.max_safe_integer which states > The value of Number.MAX_SAFE_INTEGER is the largest integer n such that n and n + 1 are both exactly representable as a Number value. On Sun, May 6, 2018 at 10:47 AM, Anders Rundgren < [email protected]> wrote: > On 2018-05-06 18:40, Isiah Meadows wrote: > >> Technically, "safe" in this context means "can you store this number *and >> all numbers below it* without loss of precision", and for every single one >> of these numbers, you can still add one to them. When you get up to 2^53, >> you can no longer add just 1 - you can only add 2 or more. This is based on >> the number of significand bits - 2^53 - 1 has all lower 53 bits set and its >> exponent set to 0 (ignoring bias). You can precisely store up to this >> number without having to adjust the exponent, no more. This is what is >> meant by "safe". (The terminology of "exactly representable" is a misnomer >> - the highest integer you can theoretically represent without loss of >> precision is `(2^53-1) * (2^971)`.) >> > > Thanx Isiah, > I (sort of) understand :-) > > Anyway, this definition departs from similar definitions in other > languages and AFAICT, existing JavaScript implementations have no problems > using 2^53 as an integer. > > > var t = 9007199254740992 > < undefined > > t-1 > < 9007199254740991 > > t > < 9007199254740992 > > For JavaScript this may be of limited importance but for (I-)JSON > canonicalization [1] it is vital that all parties do the same > interpretation. > That is, for I-JSON the 2^53-1 limitation is simply put wrong. > > Anders > > 1] https://github.com/cyberphone/json-canonicalization#json-can > onicalization > > > >> This SO answer should help explain the situation better: >> https://stackoverflow.com/a/1848762 >> >> >> ----- >> >> Isiah Meadows >> [email protected] <mailto:[email protected]> >> www.isiahmeadows.com <http://www.isiahmeadows.com> >> >> On Sun, May 6, 2018 at 11:58 AM, Anders Rundgren < >> [email protected] <mailto:[email protected]>> >> wrote: >> >> If you write >> Number.MAX_SAFE_INTEGER >> into a browser console it will return >> 9007199254740991 >> >> I believe this is wrong, 9007199254740992 the largest correct safe >> integer using IEEE-754 double precision. >> >> Using my own IEEE-754 debugger: >> >> Input floating point: 9007199254740991 >> Hex value: 433fffffffffffff >> Binary value: 0 10000110011 111111111111111111111111111111 >> 1111111111111111111111 >> >> Input floating point: 9007199254740992 >> Hex value: 4340000000000000 >> Binary value: 0 10000110100 000000000000000000000000000000 >> 0000000000000000000000 >> >> Using an external IEEE-754 debugger: >> http://www.binaryconvert.com/result_double.html?decimal=0570 >> 48048055049057057050053052055052048057057050 < >> http://www.binaryconvert.com/result_double.html?decimal=057 >> 048048055049057057050053052055052048057057050> >> >> Anders >> _______________________________________________ >> es-discuss mailing list >> [email protected] <mailto:[email protected]> >> https://mail.mozilla.org/listinfo/es-discuss < >> https://mail.mozilla.org/listinfo/es-discuss> >> >> >> > _______________________________________________ > es-discuss mailing list > [email protected] > https://mail.mozilla.org/listinfo/es-discuss >
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
