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

BigInt Shipping in Firefox

wingolog.org

Post reply on HN
Print view View original

61–70 of 172 posts

Re: BigInt Shipping in Firefox

#61

Post by tyingq »

zamadatix wrote: post #36
callahad wrote: post #23

Earlier quoted context omitted.

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 f…

Only in JS do people seem okay with constantly mucking with built-ins.

Python3 mucked with built in types...

Re: BigInt Shipping in Firefox

#62

Post by kccqzy »

philbarr wrote: post #7

I feel sorry for whoever has to write the polyfill for this...

Have you tried implementing a simple bigint library? Except for division everything is easy. I can even write it in assembler, and for example addition is just an add instruction followed by some adc instructions. Subtraction likewise. Assuming you want grade school multiplication (not Karatsuba or something fancy) it's also straightforward.

Re: BigInt Shipping in Firefox

#63

Post by kccqzy »

derefr wrote: post #18
philbarr wrote: post #7

I feel sorry for whoever has to write the polyfill for this...

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…

A more popular approach of building a bigint library is to store a number of a series of limbs, where each limb is an unsigned 32-bit or 31-bit quantity. Since IEEE754 double allows exact integer arithmetic up to 2^53, that's fine.

Re: BigInt Shipping in Firefox

#64

Post by ghettoimp »

callahad wrote: post #40
Spivak wrote: post #34

Earlier quoted context omitted.

I'm sure its for backwards compatibility but hot damn is that one hell of a footgun. Even with that in place would you ever feel confident returning an id that didn't fit in a double knowing the sheer amount of code that definitely didn't handle that case?

Only Strings are safe, forty years past K&R. Wish I knew Tcl.

I like your haiku.

But stay away from TCL...

It is such a mess.

Re: BigInt Shipping in Firefox

#65

Post by riquito »

Spivak wrote: post #34
callahad wrote: post #23

Earlier quoted context omitted.

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 f…

I'm sure its for backwards compatibility but hot damn is that one hell of a footgun. Even with that in place would you ever feel confident returning an id that didn't fit in a double knowing the sheer amount of code that definitely didn't handle that case?

> third party ids are not yours. Treat them as strings, the other party can change them to string any day (happened to me more than once over the years) or they could use a different integer size than what you support (this case, or an unlimited integer value type - some languages have that too)

Re: BigInt Shipping in Firefox

#66

Post by spankalee »

philbarr wrote: post #7

I feel sorry for whoever has to write the polyfill for this...

JSBI[1] is a polyfill for the BigInt semantics, without the syntax. Then there's a Babel transform[2] to compile to the native syntax if all your targets support it.

[1]: https://github.com/GoogleChromeLabs/jsbi

[2]: https://github.com/GoogleChromeLabs/babel-plugin-transform-j...

Re: BigInt Shipping in Firefox

#67

Post by lucb1e »

mschuetz wrote: post #26
andreigheorghe wrote: post #9

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.

Python has only Number though, and that can get as large as fits in your memory. Not sure why they didn't ship this with decimals and enabled it by default in javascript.

I once wrote a replacement for the + operator in javascript because computers can't do proper addition (0.1+0.2!=0.3). It was basically remembering the sign and handling some other notation like 1e100, splitting on the dot, and adding them up the normal way (as integers). To merge the result of the two additions, take care of the carry (if any) and concatenate the two numbers again with a dot.

So from my primitive understanding, if you're already storing a variable-length number (a space win in most cases, compared to the previous 4-byte float), you might as well store two variable-length numbers. Something like ABxx xxxx for the first byte, where if A=0 there is no decimal part (no second variable-length number) and if B=0 there is no next byte (the variable length part of it), then use Bxxx xxxx for each following byte. Then you have arbitrary size and decimals with perfect addition (no floating point approximations anymore).

Would it be that much slower, that it's an awful idea to do by default? Like, would it be noticeable on an average website with the usual godawful amount of javascript? Python gets away with it, so that would be weird. And you could still introduce special syntax (like, I don't know, suffixing an n maybe) to use old and faster primitive types for those who really need that.

Re: BigInt Shipping in Firefox

#68

Post by jfk13 »

tzs wrote: post #45
bpye wrote: post #39

Earlier quoted context omitted.

You can certainly serialize to a string but knowing when you should revive to a BigInt seems tricky. You could prefix the strings I guess?

How about serializing to an array ["bigint", "170141183460469231731687303715884105727"]? It takes more space, but is easy to recognize, and easy to generalize to other types.

Presumably that could be confusing if you ever happen to have an actual array whose first element is the string "bigint".

Re: BigInt Shipping in Firefox

#69

Post by jchw »

coolreader18 wrote: post #60
jchw wrote: post #52

Earlier quoted context omitted.

I’m super strongly against this concept actually, which you might gather from mention of lodash.

I think they were making a joke.

Obviously it was some degree of tongue-in-cheek, but I’m not really that amused, to be honest. It needs a leftpad reference or something.

Re: BigInt Shipping in Firefox

#70

Post by opencl »

dlbucci wrote: post #43

Kind of bummed this is a new primitive type. Every instance of `typeof a === 'number'` just became `typeof a === `number` || typeof a === 'bigint'`... EDIT: The more I think about it (and the more comments I get), the more I think this might actually be a good thing. I think bigint will probably not be used in places where integer numbers are currently used, and it might be unreasonable to expect code to work with nu…

For code that actually needs bigints mixing numbers and bigints is just asking for horrible bugs like when a bunch of Twitter clients completely broke after 2^53 posts had been made.
Post reply on HN