Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

BigInt is finally here in ES2020

developer.mozilla.org

Post reply on HN
Print view View original

11–20 of 21 posts

Re: BigInt is finally here in ES2020

#11

Post by MaxBarraclough »

seritools wrote: post #10
MaxBarraclough wrote: post #9

Earlier quoted context omitted.

> The point is that not all integers over `Number.MAX_SAFE_INTEGER` can be represented. Some can, of course. Right. This contradicts the article. > 2^53 - 1 comes from the 64-Bit floating point representation JS uses Right.

Ah, now I see it the whole point - "reliably representable" not meaning the same as "safe", gotcha.

Sort of. I'm pointing out what seems to me to be an incorrect statement in the article. I think it's reasonable to have special terminology for the sequence of contiguous integers which can be represented exactly in the Number type. Safe seems a reasonable choice, provided it's used carefully.

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.

Re: BigInt is finally here in ES2020

#12

Post by orra »

MaxBarraclough wrote: post #8
smitop wrote: post #6

Earlier quoted context omitted.

I think you misread the sentence. It's not the largest value JS can represent, it's the largest value it can "reliably represent". After 2^53 - 1 you get incorrect results when dealing with integers, making the results not "reliable".

When an integer can be reliably represented , that presumably 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 on it and get back another integer, also represented exactly. Trivially, there are no such values. Every non-negative integer up to and including…

I can't agree with your pedantry here.

> 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.

Re: BigInt is finally here in ES2020

#13

Post by MaxBarraclough »

orra wrote: post #12
MaxBarraclough wrote: post #8

Earlier quoted context omitted.

When an integer can be reliably represented , that presumably 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 on it and get back another integer, also represented exactly. Trivially, there are no such values. Every non-negative integer up to and including…

I can't agree with your pedantry here. > 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 arbitrar…

> you're putting a lot of meaning into what you admit is an assumption

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.

Re: BigInt is finally here in ES2020

#14

Post by Caligatio »

MaxBarraclough wrote: post #4

> BigInt is a built-in object that provides a way to represent whole numbers larger than 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. 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…

I maintain a JavaScript hashing library and the language's handling of large integers is terrible. SHA-256/SHA-384/SHA-512 as well as SHA-3 all use 64-bit primitives so I need to do some hacks to emulate a 64-bit integer. Bit shifting large numbers gets even more nebulous...

Re: BigInt is finally here in ES2020

#15

Post by MaxBarraclough »

Caligatio wrote: post #14
MaxBarraclough wrote: post #4

> BigInt is a built-in object that provides a way to represent whole numbers larger than 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. 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…

I maintain a JavaScript hashing library and the language's handling of large integers is terrible. SHA-256/SHA-384/SHA-512 as well as SHA-3 all use 64-bit primitives so I need to do some hacks to emulate a 64-bit integer. Bit shifting large numbers gets even more nebulous...

Do you know if moving to BigInt would cause performance issues?

Re: BigInt is finally here in ES2020

#16

Post by zeroimpl »

Lx1oG-AWb6h_ZG0 wrote: post #2

> Using JSON.stringify() with any BigInt value will raise a TypeError as BigInt values aren't serialized in JSON by default. However, you can implement your own toJSON method if needed 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

I’m sure they could make stringify work, since numbers in JSON can be arbitrarily large. But parsing JSON and having it return BigInt instead of Number just isn’t going to be able to work by default. I guess because of this, making stringify work without parse support just isn’t desirable.

Re: BigInt is finally here in ES2020

#17

Post by postalrat »

zeroimpl wrote: post #16
Lx1oG-AWb6h_ZG0 wrote: post #2

> Using JSON.stringify() with any BigInt value will raise a TypeError as BigInt values aren't serialized in JSON by default. However, you can implement your own toJSON method if needed 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

I’m sure they could make stringify work, since numbers in JSON can be arbitrarily large. But parsing JSON and having it return BigInt instead of Number just isn’t going to be able to work by default. I guess because of this, making stringify work without parse support just isn’t desirable.

Where do you read numbers can be arbitrarily large? I thought it was limited to javascript numbers.

Re: BigInt is finally here in ES2020

#18

Post by postalrat »

Lx1oG-AWb6h_ZG0 wrote: post #2

> Using JSON.stringify() with any BigInt value will raise a TypeError as BigInt values aren't serialized in JSON by default. However, you can implement your own toJSON method if needed 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 bigints aren't part of the json spec? Like they said you create your own toJSON like: 'BigInt.prototype.toJSON = function() { return this.toString(); };' if you want to bend the spec.

Re: BigInt is finally here in ES2020

#19

Post by dragonwriter »

Lx1oG-AWb6h_ZG0 wrote: post #2

> Using JSON.stringify() with any BigInt value will raise a TypeError as BigInt values aren't serialized in JSON by default. However, you can implement your own toJSON method if needed 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

> Sorry, why exactly can’t they also define the json.parse/stringify behavior of bigints?

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.

Re: BigInt is finally here in ES2020

#20

Post by dragonwriter »

postalrat wrote: post #18
Lx1oG-AWb6h_ZG0 wrote: post #2

> Using JSON.stringify() with any BigInt value will raise a TypeError as BigInt values aren't serialized in JSON by default. However, you can implement your own toJSON method if needed 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 bigints aren't part of the json spec? Like they said you create your own toJSON like: 'BigInt.prototype.toJSON = function() { return this.toString(); };' if you want to bend the spec.

> Because bigints aren't part of the json spec?

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.

Post reply on HN