BigInt is finally here in ES2020(developer.mozilla.org) |
BigInt is finally here in ES2020(developer.mozilla.org) |
Sorry, why exactly can’t they also define the json.parse/stringify behavior of bigints? JSON was initially derived from JavaScript, so it seems a bit weird that a new ES standard can’t interoperate with json
Because every construct in JSON already has a defined way that it is parsed into JS and incorporating BigInt into that by default would break backwards compatibility of JS’s JSON handling.
Interop concerns make the right JSON serialization very application dependent, too.
Arbitrarily sized numbers (with no guarantee on supported range or precision in processors) are part of the spec, the problem is JS already serializes/deserializes them as Number and any change would break backwards compatibility.
Isn't this wrong? JavaScript's Number type can represent some integers vastly greater than this. [0] What's special about Number.MAX_SAFE_INTEGER, if I understand correctly, is that it's the smallest integer such that (Number.MAX_SAFE_INTEGER + 1) is not guaranteed to be represented faithfully by the Number type.
Given the topic, I don't think I'm being pedantic.
edit On second thought, I could well be mistaken. The definition of JavaScript's Number type might be such that no guarantees are made about which integers greater than Number.MAX_SAFE_INTEGER can be represented exactly.
edit 2 Nope, Number.MAX_VALUE is defined to be an integer. [0] Which is to say, the largest whole number that can be represented is Number.MAX_VALUE, not Number.MAX_SAFE_INTEGER. Of course, it's not the case that Number is guaranteed to be able to exactly represent all non-negative integers less than Number.MAX_VALUE, but that isn't the same thing. The article appears to get this wrong.
[0] https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
That 2^53 - 1 comes from the 64-Bit floating point representation JS uses for the normal number type.
(Number.MAX_SAFE_INTEGER + 1) === (Number.MAX_SAFE_INTEGER + 2)
> true
Right. This contradicts the article.
> 2^53 - 1 comes from the 64-Bit floating point representation JS uses
Right.
Every non-negative integer up to and including Number.MAX_SAFE_INTEGER can be represented exactly by the Number type, in any compliant JavaScript implementation. It's also true though that Number.MAX_VALUE is itself defined to be an integer. It's therefore not true to say that Number.MAX_SAFE_INTEGER is the greatest integer that can be exactly represented by JavaScript's Number type.
Instead, Number.MAX_SAFE_INTEGER is the greatest integer such that Number.MAX_SAFE_INTEGER can be represented precisely by the Number type, and all non-negative integers less than Number.MAX_SAFE_INTEGER can be represented exactly by the Number type. (See also my second edit to my earlier post.)
It seems incorrect then that the article states:
> 2^53 - 1, which is the largest number JavaScript can reliably represent with the Number primitive and represented by the Number.MAX_SAFE_INTEGER constant
There's discussion of the term safely represent on the MAX_SAFE_INTEGER page. [0]
[0] https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
RFC 8259, Section 6, specifies unlimited number of digits for the integer and fraction parts, but allows implementations to have size and precision constraints.
> I thought it was limited to javascript numbers.
It suggest that IEEE754 binary64, because it is widely available and supported, should generally be safely usable (which happens to be exactly JavaScript numbers) but it does not limit JSON numbers to that range/precision.
> When an integer can be reliably represented, that presumably
You are right that the wording is not precise, but now you're putting a lot of meaning into what you admit is an assumption.
> means that JavaScript's definition of the Number type is such that it guarantees that a given integer can be represented exactly by the Number type. It doesn't mean you can safely do arbitrary integer arithmetic
Who said arbitrary? The natural numbers are canonically represented by a successor function, denoted S(n). So we're talking about the highest natural that can be represented as such.
Can you suggest another interpretation? It's a point about representing a number, and is not a point about arithmetic, so I'm not seeing what else it could mean.
Either way we're agreed that it wants reworking. Technical documentation should not be incorrect, as I believe it to be, and it should not be ambiguous, as you believe it to be.
> Who said arbitrary?
Look at what I was responding to: After 2^53 - 1 you get incorrect results when dealing with integers, making the results not "reliable". That's not very precise, as dealing with might refer to the problem of exactly representing the integer values in the Number type, or it might refer to the problem of doing arithmetic with those values and getting exact results.
To rephrase my point: with the exception of 0, there is no Number value x such that, for all integer Number values y, the integer x + y can be represented exactly as a Number. It's not 'safe' to compute Number.MAX_SAFE_INTEGER + 1 despite that both terms are 'safe' integers.
Which is to say, we need to be clear that we're reasoning about the problem of exactly representing integer values in the Number type.
> The natural numbers are canonically represented by a successor function, denoted S(n). So we're talking about the highest natural that can be represented as such.
I don't see your point here. I've already discussed the difference between Number.MAX_SAFE_INTEGER and the much greater integer Number.MAX_VALUE.
MAX_SAFE_INTEGER seems a better choice of identifier than something like MAX_VALUE_OF_EXACTLY_REPRESENTABLE_CONTIGUOUS_SEQUENCE_OF_INTEGERS, of course, despite that it's less precise. (Even that absurdly long identifier isn't perfectly precise, as we can define a trivial sequence of a single value like Number.MAX_VALUE.) The documentation explaining it should be precise, though.