Discuss
  • Clarify integer and safe integer resolution

Clarify integer and safe integer resolution

# Rick Waldron (12 years ago)

At the last TC39 meeting we discussed the addition of the following items:

Number.MAX_SAFE_INTEGER = (2^53)-1

Number.isInteger
  - Infinity => false
  - NaN => false
  - value !== truncated value => false
  - -0 => true

Number.isSafeInteger
  - -0 => true

This resolution of record doesn't include a consensus on these extensions as defined, but IIRC there was consensus on Mark's proposal. Jeff Walden noted that there was no clear resolution and I apologize for this oversight.

# Mark S. Miller (12 years ago)

What I remember, rephrased using code

Number.MAX_SAFE_INTEGER = (2^53)-1;

yes. Presumably

Number.MIN_SAFE_INTEGER = -Number.MAX_SAFE_INTEGER;

Number.isSafeInteger(n) {
    return typeof n === 'number' &&
        Math.round(n) === n &&
        Number.MIN_SAFE_INTEGER <= n &&
        n <= Number.MAX_SAFE_INTEGER;
}

This has the important guarantee that isSafeInteger(a) && isSafeInteger(b) && isSafeInteger(a+b) together imply that a+b is the accurate sum of a and b.

Also

isSafeInteger(NaN) // false
isSafeInteger(new Integer(2)) // false
isSafeInteger(-0) // true
isSafeInteger(Infinity) // false

We also decided that toInteger is not needed given the other similar coercion methods already on Math.

As for Number.isInteger, I don't remember.

# Allen Wirfs-Brock (12 years ago)

The rev17 spec. draft includes th specification of these function based uopn my understanding of the agreement at the meeting. people.mozilla.org/~jorendorff/es6-draft.html#sec-15.7.2.8, people.mozilla.org/~jorendorff/es6-draft.html#sec-15.7.2.13, people.mozilla.org/~jorendorff/es6-draft.html#sec-15.7.2.14

If anyone see any issues with these definitions then they should file some bugs.

# Mark S. Miller (12 years ago)

I'm not sure the following is a bug, so discussing on es-discuss first before filing one.

I agree that during the meeting we explicitly discussed MAX_SAFE_INTEGER but not MIN_SAFE_INTEGER, which is why I wrote "presumably" in my previous message. But I think it violates both consistency with the rest of the API and the principle of least surprise to omit MIN_SAFE_INTEGER. We should just include the obvious definition of it, as in my pseudocode above. If no one disagrees, I'll file a bug. Thanks.