Re: Number.MAX_SAFE_INTEGER incorrect?

On 2018-05-06 21:37, Mark Miller wrote: I take that back. The rfc says: An I-JSON sender cannot expect a receiver to treat an integer whose absolute value is greater than 9007199254740991 (i.e., that is outside the range [-(2**53)+1, (2**53)-1]) as an exact value. For the natural

Re: Number.MAX_SAFE_INTEGER incorrect?

I take that back. The rfc says: An I-JSON sender cannot expect a receiver to treat an integer whose absolute value is greater than 9007199254740991 (i.e., that is outside the range [-(2**53)+1, (2**53)-1]) as an exact value. For the natural interpretation of "treat" as in "operate on

Re: Number.MAX_SAFE_INTEGER incorrect?

Hi Anders, you are correct. The rfc as stated is incorrect. The EcmaScript spec is correct. 2**53 is indeed exactly representable, which is what the rfc is about. But 2**53 is not safe, which what the ecmascript spec is about. On Sun, May 6, 2018 at 11:58 AM, Anders Rundgren <

Re: Number.MAX_SAFE_INTEGER incorrect?

On 2018-05-06 19:57, Logan Smyth wrote: 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

Re: Number.MAX_SAFE_INTEGER incorrect?

Oops. Should be: if (isSafeInteger(a) && isSafeInteger(b)) { const c = a + b; if (isSafeInteger(c)) { // c is actually the sum of a and b } } ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss

Re: Number.MAX_SAFE_INTEGER incorrect?

motivation: if (isSafeInteger(a) && isSafeInteger(b)) { const c = a + b; if (isSafeInteger(b)) { // c is actually the sum of a and b } } On Sun, May 6, 2018 at 10:57 AM, Logan Smyth wrote: > To clarify, the "you can still add one to them" is probably the most

Re: Number.MAX_SAFE_INTEGER incorrect?

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.

Re: Number.MAX_SAFE_INTEGER incorrect?

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

Re: Number.MAX_SAFE_INTEGER incorrect?

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

Number.MAX_SAFE_INTEGER incorrect?

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:

Re: something wrong about generator

>or it need to return {value: {value: "end", done: true}, done: true} this case is supported, seems, if to use: function* b() { return yield* a() } ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss

something wrong about generator

generator function shouldn't allow a "return value" when use yield or it need to return {value: {value: "end", done: true}, done: true} at the iter end when use yield* code: ``` javascript function* a() { yield 1; yield 2; return "end" } //undefined function* b() { yield* a() } //undefined c =