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

151–160 of 172 posts

Re: BigInt Shipping in Firefox

#151

Post by camgunz »

rayiner wrote: post #144
ska wrote: post #142

Earlier quoted context omitted.

lua does the same thing. It's not crazy.

Failing to distinguish between integer and floating point types is crazy. Not as crazy as TCL’s everything being a strong, but not the work of a mentally well person.

"Numbers" actually conceal a lot of complexity.

Is 2 between 1.9 and 2.1? What about between 1.9 and 2.1111111111111111111111111111111111111111?

What about over/underflow? Do you wrap, clamp, throw an exception? Do you round or set +-inf? Can you divide by zero? Can you divide an integer by a floating point number, and if so what would the result be?

What happens if, say, you multiply an 8-bit and 16-bit integer and the result (using twos complement) doesn't fit in 8 bits?

"Use IEEE-754 doubles for everything" answers all these questions. I think JavaScript is basically junk, but I find at least this aspect to be rather elegant (to the point that I suspect it came from somewhere else, haha).

Re: BigInt Shipping in Firefox

#152

Post by saurik »

cwzwarich wrote: post #130
wahern wrote: post #117

Earlier quoted context omitted.

JavaScript can't easily evolve past the optimization tricks used in the major implementations. They all heavily rely on NaN tagging which makes 64-bit value types problematic. For similar reasons the architecture of V8 in particular has effectively dictated the design of WebAssembly, especially regarding control flow constructs like goto and coroutines.

> For similar reasons the architecture of V8 in particular has effectively dictated the design of WebAssembly, especially regarding control flow constructs like goto and coroutines. The weirdness of WebAssembly with regards to control flow constructs is rooted in Emscripten's "relooper", which was developed in a naive manner ignoring previous (superior) research on irreducible control flow.

I am pretty sure the reason for this is that alternative designs for control flow cannot be implemented in linear time; Java, for example, has experienced epic denial of service attack issues on their verifier design, where code of specific forms leads to quadratic verification time.

Re: BigInt Shipping in Firefox

#153

Post by AlexMax »

wahern wrote: post #149
ska wrote: post #142

Earlier quoted context omitted.

lua does the same thing. It's not crazy.

Lua 5.3 added 64-bit integers along with native bitwise operators. There's no end of bickering on the mailing-list over the finer details, but without a doubt 64-bit integers is a win.

> without a doubt 64-bit integers is a win

I'm not so sure about that. There is an alternative implementation of Lua called LuaJIT, which uses a similar NaN-tagging trick, and it also happens to be incredibly fast. LuaJIT uses the 5.1 version of the language, with some backported 5.2 features for compatibility, but it will likely never backport 64-bit integers from 5.3.

It's resulted in something like the Python 2/3 split. Except it's even worse because Lua has relatively little penetration as a general purpose scripting language, but is quite popular as a language that can be embedded in a program to add scripting capabilities. This means it's up to the developer of said program which version of Lua they choose to embed, and from what I can tell, most developers choose speed over 64-bit integer support.

Re: BigInt Shipping in Firefox

#154

Post by ratel »

darknoon wrote: post #37
mcaruso wrote: post #11

Earlier quoted context omitted.

JSON serialization does not seem to be supported yet. `JSON.serialize(42n)` gives me a TypeError "Do not know how to serialize a BigInt" in Chrome. Deserialization support also doesn't exist as far as I'm aware. Would be great to be able to choose to decode integer JSON literals as BigInt, but I'm not holding my breath.

You could decode all of them as BigInt, but then you would be accepting a large overhead for the much greater number of constants like 1 or 42 where it's unnecessary. Everywhere you pass that JSON data would need to be updated to operate in terms of BigInt instead of number. If you only decoded big ones as BigInt, you would have the same problem of updating the code but now you have 2 codepaths at every callsite! It'…

You need some way of serialization that makes clear it was serialized as a BigInt and thus must be de serialized as a BigInt without the likelihood of it misinterpreting the data like 9n being a tractor model. A single indicator would be too error prone, so the schema has to be more complex. With that complexity it needs to perform and be (cheaply) verifiable.

Quickest thing I can think of is storing it as power of 2 + the difference ending with character n as good measure. It is easy to serialize/de-serialize and you can verify the number by re-serializing to be a proper BigInt and not for instance a String. Confusion still would be possible, but rare. So 1 would be stored as 0+1n, 42 would be stored as 5+10n, etc.

Re: BigInt Shipping in Firefox

#155

Post by Stratoscope »

GordonS wrote: post #120
ClassyJacket wrote: post #118

Earlier quoted context omitted.

Yeah - plus Javascript doesn't even support 32 bit integers.

Eh? What exactly is JavaScript's numeric type then? I always presumed it was a 32-bit, signed integer..

> What exactly is JavaScript's numeric type then? I always presumed it was a 32-bit, signed integer.

It's not ideal to presume such a thing when there are ways to find out the answer, either from the link in a sibling comment or by observing JavaScript code that uses the Google Maps API or similar mapping APIs. How would you represent a latitude or longitude with a 32-bit integer?

I don't mean to pick on you. I have made these same kinds of assumptions too many times and it always got me in trouble.

Here's a particularly embarrassing example. When I did my first election results map for Google, I needed a way to represent the outline of a state. I saw that the Maps API supported polygons, so I thought "that's great, I can use a polygon for each state!"

Until the map went live and someone asked me "What happened to the northern part of Michigan [which isn't connected to the rest of the state]? And where are the rest of the Hawaiian Islands?"

It turned out that a single polygon wasn't enough to represent the outline of a state. Who would have guessed?

Don't let this happen to you. :-)

Re: BigInt Shipping in Firefox

#156

Post by SomeOldThrow »

cpeterso wrote: post #78

BitInt's "n" suffix appears to stand for "numeric", but that seems confusing when typeof 1 === "number" and typeof 1n === "bigint" . Why not an "i" suffix for "integer"? I understand that a "b" suffix is probably reserved in case JavaScript adds support for binary literals. https://tc39.github.io/proposal-bigint/#prod-BigIntLiteralSu...

> BitInt's "n" suffix appears to stand for "numeric"

It actually stands for "not numeric"

Re: BigInt Shipping in Firefox

#157

Post by rayiner »

nine_k wrote: post #147
rayiner wrote: post #144

Earlier quoted context omitted.

Failing to distinguish between integer and floating point types is crazy. Not as crazy as TCL’s everything being a strong, but not the work of a mentally well person.

It's a work of RAM-constrained and time-constrained people in early 1990s, following approaches developed on 1970s for Lisp. Packing as much as possible into a single cons cell, or a JS value, was (and is) important, so bit masking to distinguish between integers, floats, strings, functions, objects, was an inevitable approach.

Lisp has distinct integer and floating point types with the correct behavior for those types. At runtime they might get passed around as tagged data, but that’s not visible in the language semantics. In JavaScript, by contrast, the language exposes only a double float rule and you have to use floats where you’d otherwise use integers.

Re: BigInt Shipping in Firefox

#158

Post by frutiger »

qwerty456127 wrote: post #97

Now let's wait another decade before they add BigDecimal...

While not directly related to BigDecimal, my employer (Bloomberg) primarily sponsored this effort through the arduous TC39 process and sponsored the implementation in any browser vendor that wanted primarily as a stepping stone to standardising decimal floating point.

We see BigInt as a relatively uncontroversial but important extension of the numeric type system of JavaScript. Once the door is open for a type that is not immediately compatible with Number, potentially new numeric types can be introduced. Perhaps BigDecimal (or Rational?) can follow.

Re: BigInt Shipping in Firefox

#159

Post by nine_k »

rayiner wrote: post #157
nine_k wrote: post #147

Earlier quoted context omitted.

It's a work of RAM-constrained and time-constrained people in early 1990s, following approaches developed on 1970s for Lisp. Packing as much as possible into a single cons cell, or a JS value, was (and is) important, so bit masking to distinguish between integers, floats, strings, functions, objects, was an inevitable approach.

Lisp has distinct integer and floating point types with the correct behavior for those types. At runtime they might get passed around as tagged data, but that’s not visible in the language semantics. In JavaScript, by contrast, the language exposes only a double float rule and you have to use floats where you’d otherwise use integers.

I agree. A Lisp may not make available all bits of a machine word to an integer, but they won't mix up an integer and a float.

JavaScript tried to make things artificially "simpler" by implicit conversions. As usual, the lack of consistency only lead to more eventual complexity than a sound solution would have in the first place.

Re: BigInt Shipping in Firefox

#160

Post by fgonzag »

wvenable wrote: post #146
fgonzag wrote: post #139

Earlier quoted context omitted.

Anybody who thinks that's actually good (or even real) advice is going to write horrible code regardless, IMHO.

https://www.npmjs.com/browse/depended/is-number

That's horrifying, I thought the whole isNumber thing was a joke.

Do these guys assemble their application as hundreds (or thousands) of NPM packages containing single functions and then import them together? Because now I actually believe they are capable of it.

Post reply on HN