Live data from Hacker News

BigInt Shipping in Firefox

wingolog.org

21–30 of 172 posts

Re: BigInt Shipping in Firefox

#21
post #10
post #5

Anyone knows how does bigint serialization and deserialization to JSON look like in practice in Chrome and Firefox?

Afaict, JSON serialization is not supported yet, got a "TypeError: BigInt value can't be serialized in JSON". I'm on Firefox Developer edition 68.0b3.

I suppose one could use a replacer[0] when calling JSON.stringify and a reviver[1] when calling JSON.parse

[0] https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

[1] https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

Re: BigInt Shipping in Firefox

#22
> This contrasts with JavaScript number values, which have the well-known property of only being able to precisely represent integers between -2⁵³ and 2⁵³.

JS's Number can represent way more integers than just those between -2⁵³ and 2⁵³. There's a great StackOverflow answer[1] that answers a similar question, ("What is the biggest "no-floating" integer that can be stored in an IEEE 754 double type without losing precision?") which also applies here (A JS Number is an IEEE double):

> The biggest/largest integer that can be stored in a double without losing precision is the same as the largest possible value of a double. That is, DBL_MAX or approximately 1.8 × 10³⁰⁸ (if your double is an IEEE 754 64-bit double). It's an integer. It's represented exactly. What more do you want?

> Go on, ask me what the largest integer is, such that it and all smaller integers can be stored in IEEE 64-bit doubles without losing precision. An IEEE 64-bit double has 52 bits of mantissa, so I think it's 2⁵³:

More seriously, this is great news, and I think it'll be nice to have such a numeric type in JS.

[1]: https://stackoverflow.com/a/1848762

Re: BigInt Shipping in Firefox

#23
post #5

Anyone knows how does bigint serialization and deserialization to JSON look like in practice in Chrome and Firefox?

You can define a toJSON property on the BigInt prototype that gets used for serialization:

    Object.defineProperty(BigInt.prototype, "toJSON", {
        get() {
            "use strict";
            return () => String(this);
        }
    });
Of course you could also serialize to a Number, but that risks losing precision. For example, the Twitter API often returns IDs as both a Number ("id") and a String ("id_str") to safely handle cases where the value might fall outside of a normal double-precision float: https://developer.twitter.com/en/docs/tweets/data-dictionary...

Re: BigInt Shipping in Firefox

#24
post #18

Earlier quoted context omitted.

Bignums themselves are actually pretty easy to implement as a plain library, provided your language has a uint8-array type (not just a String type, which might require the content be utf-8 valid, or might only have facilities to operate on codepoints, or might cut the data off at the first NUL.) JS already has a Uint8Array, so bignum libraries are easy. (Let me tell you though, there were JS bignum libraries before U…

> Actually supporting the literal syntax or the operators via a plain library is impossible; but you can just do it the other way around: encourage developers to use a bignum library (for now), and have said library just “bake down” to native BigInts when they’re available. Can't you rewrite the syntax into something usable at runtime? Not that it were a good idea.

This ...might be possible, but the performance would indeed suck; you’d need to essentially ship half a compiler toolchain in your polyfill, and ensure that it gets run separately, non-async, so that the browser finishes installing it before attempting to interpret any more tags. (And, presumably, all of your app’s source would be in the next script tag, so that your app can take advantage of native bigints; so your app wouldn’t load at all until the toolchain had finished bootstrapping.)

I’m guessing this has been done, to let the browser run—without backend compilation— where foo is CoffeeScript or TypeScript or ClojureScript or what-have-you; but this one would be especially bad, because the thing it’d be targeting would still be Javascript, and so you’d have to rewrite all Javascript sources you encounter, with most of them likely never using native bigints but suffering the double-parsing overhead anyway.

Oh, and you’d have to override the ES6 module loader with one that also rewrites what it loads. Ugly.

Re: BigInt Shipping in Firefox

#25

> This contrasts with JavaScript number values, which have the well-known property of only being able to precisely represent integers between -2⁵³ and 2⁵³. JS's Number can represent way more integers than just those between -2⁵³ and 2⁵³. There's a great StackOverflow answer[1] that answers a similar question, ("What is the biggest "no-floating" integer that can be stored in an IEEE 754 double type without losing prec…

[deleted]

Re: BigInt Shipping in Firefox

#26

I'm curious why this wasn't shipped as a replacement of the existing Number type implementation, instead of this new type and syntax.

Because number is practically the same as double, and you can't just go and change double values to integer values. Also, doubles are fast. BigInts are not.

Re: BigInt Shipping in Firefox

#27

> This contrasts with JavaScript number values, which have the well-known property of only being able to precisely represent integers between -2⁵³ and 2⁵³. JS's Number can represent way more integers than just those between -2⁵³ and 2⁵³. There's a great StackOverflow answer[1] that answers a similar question, ("What is the biggest "no-floating" integer that can be stored in an IEEE 754 double type without losing prec…

You seem to be doing an uncharitable reading of what you quoted. They can precisely represent numbers outside that range, true. They cannot represent all numbers outside that range.

Re: BigInt Shipping in Firefox

#29

> This contrasts with JavaScript number values, which have the well-known property of only being able to precisely represent integers between -2⁵³ and 2⁵³. JS's Number can represent way more integers than just those between -2⁵³ and 2⁵³. There's a great StackOverflow answer[1] that answers a similar question, ("What is the biggest "no-floating" integer that can be stored in an IEEE 754 double type without losing prec…

That's obviously not what was intended by the question, come on.
Post reply on HN