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

121–130 of 172 posts

Re: BigInt Shipping in Firefox

#121

Post by lucb1e »

mschuetz wrote: post #109
lucb1e wrote: post #67

Earlier quoted context omitted.

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

> I once wrote a replacement for the + operator in javascript because computers can't do proper addition (0.1+0.2!=0.3). That's normal floating point math behaviour and fine in most use cases. You can't fix this for add, sub, mul and div without serious performance implications. > Would it be that much slower, that it's an awful idea to do by default? Yes. Easily an order of magnitude slower, perhabs two. The fixed s…

I did some testing with pypy, which also works with arbitrarily large integers but iirc does JIT instead of interpretation (like cpython would do), so that should be similar to JS in V8 except that it has arbitrarily large integers.

    a = Math.pow(2, 1023)
    t = new Date().getTime()
    for (var i = 0; i
vs

    a = pow(2, 1024)
    t = time.time()
    for i in range(int(1e7)):
        a += i
    print(time.time() - t)
Both ran a bunch of times: pypy does it in 279ms and nodejs in 250. I chose 1024 for Python because that is where JS starts to return infinity, so the JS code does operations on a number just below that. The time seems to be spent in the loop, as an empty loop or a loop doing a+=0 is 20x faster.

Lowering the exponent to 100, JS spends 269ms and pypy 142. Not sure why that is, but having arbitrarily large integers doens't seem to make this arithmetic any faster.

I don't know how to quickly toy around with fraction-based floats, but at least for arbitrarily large integers, I'm not sure why we're going to have to put up with new syntax.

Re: BigInt Shipping in Firefox

#122

Post by xtian »

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

https://developer.mozilla.org/en-US/docs/Glossary/Number

Re: BigInt Shipping in Firefox

#123

Post by GordonS »

loeg wrote: post #87
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...

1i is a bit more difficult to read than 1n in many fonts. I don't think any numeral is plausibly confused with n, so 'iNt' makes some sense as a suffix IMO.

As an aside, c# uses "L" to denote literals as 64-bit integers. "l" works too, but "L" is encouraged for the same reason you give ("l" could be confused as "1")

Re: BigInt Shipping in Firefox

#124

Post by GordonS »

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

64-bit integers are referred to as 'long' in languages I'm more familiar with, so personally I would have expected an "L" suffix. 32-bit integers are referred to as 'integers' in many languages, so I wouldn't expect an 'i' suffix. In any case, I certainly agree that "n" is confusing since Javascript already has a numeric type.

Re: BigInt Shipping in Firefox

#125

Post by vbezhenar »

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

JavaScript uses double. Though its precision is more than enough to support 32 bits. Actually it supports 53 bits for integers, then it gets imprecise.

Re: BigInt Shipping in Firefox

#126

Post by lucb1e »

School-Cotton wrote: post #115
lucb1e wrote: post #112

Earlier quoted context omitted.

> [first two paragraphs] Do you really expect I mentioned this example, mentioned I wrote some code that solves this issue, and still never looked up or came across an explanation of why most programming languages behave this way? > If you are ever calling == on floating point numbers, you are doing something seriously wrong. Not sure if the 'you' is actually directed to me or if it could be replaced with 'one', but…

> Do you really expect I mentioned this example, mentioned I wrote some code that solves this issue, and still never looked up or came across an explanation of why most programming languages behave this way? Well, what you described does not actually solve the issue despite you claiming that it has, so I thought you might be confused. Which is not an insult -- many people are confused about this issue. And you appear…

> Your "fix" makes it so that 1/10 + 2/10 == 3/10, but it still doesn't make it so that 1/3 + 1/3 == 2/3. So how is it actually "precise"?

Fair point! I don't think anyone ever put it quite this way. I mean, I knew that 1/3 cannot be represented in decimal and that decimal, like binary, is imprecise for the exact same reason, but I don't think anyone asked me about the definition of precise and why I think my version of addition fits that definition of precise better :). I think the answer is that, in code, we type in decimal: 0.1+0.2 and not 0b0.1+0b0.10 (if that would even be valid syntax). We work in base 10 most of the time, so we know that operations on 1/3 can not have infinite precision. But that's just something I came up with on the spot, I'm not sure that this is the true reason why it feels more correct.

> It doesn't really matter whether it would make the average website slower, since the average website should not be using floats

Fair enough about floats, but why about arbitrarily large integers? The feature being introduced could have been introduced as 'works out of the box' instead of 'opt in using the n suffix'.

Actually, I just realized it would probably break code that does bit shifts. Maybe that's why bigint is not the default?

Re: BigInt Shipping in Firefox

#127

Post by AgentME »

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…

You can't do arithmetic with numbers and bigints, so when would you ever accept a parameter that could either be a number or a bigint? The places that `typeof a === `number` || typeof a === 'bigint'` could be used seem rare to me.

Re: BigInt Shipping in Firefox

#128

Post by dfox »

recursive wrote: post #114
lucb1e wrote: post #105

Earlier quoted context omitted.

Oh, my bad. I thought those were abstracted away. Still though, any int can get as large as you like by default, no weird -n suffix (that I never saw in any other language -- just like most of Javascript's other recently added syntax, by the way, it's the new Perl). I do wonder where I got this notion of Number. Is there some other language that has this?

I think stuff like wolfram language and mathematica probably have some "universal" numeric type. However, I don't know a single mainstream application programming language that has a single numeric type that can handle: arbitrarily large integers, floating point values, and correct decimal arithmetic (0.1 + 0.2 == 0.3). I have at least a passing familiarity with probably about a dozen general purpose programming lang…

Common name for what you call "universal numeric type" is "number tower". Most lisp dialects have something like that. What that means is that you have classes for small integers (fixnum), arbitrary precision integers (bignum), fractions, floats, and even complex numbers along with the appropriate abstract base classes (eg. integer, rational, real...) and arithmetic operations transparently use the most appropriate type for the result, i.e. the result of "1 / 10" comes out as "1/10" (of type fraction) and not as float "0.500...something".

Python 3 has mostly same approach to number types.

Re: BigInt Shipping in Firefox

#129

Post by batmansmk »

ClassyJacket wrote: post #118
vngzs wrote: post #19

Here is the proposal[0]. There are important real use cases for this. I authored an implementation of the FNV64 hash function[1] at my last job. I needed to use the BigInteger.js[2] library. It truly surprised me that Javascript in 2018 did not support something so simple as 64-bit integers. [0]: https://tc39.github.io/proposal-bigint/ [1]: https://golang.org/src/hash/fnv/fnv.go [2]: https://github.com/peterolson/Big…

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

You are right. We can store and manipulate Int32 arrays as a typedarrays. The arithmetic is limited to a few operations.

Re: BigInt Shipping in Firefox

#130

Post by cwzwarich »

wahern wrote: post #117
vngzs wrote: post #19

Here is the proposal[0]. There are important real use cases for this. I authored an implementation of the FNV64 hash function[1] at my last job. I needed to use the BigInteger.js[2] library. It truly surprised me that Javascript in 2018 did not support something so simple as 64-bit integers. [0]: https://tc39.github.io/proposal-bigint/ [1]: https://golang.org/src/hash/fnv/fnv.go [2]: https://github.com/peterolson/Big…

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.

Post reply on HN