Earlier quoted context omitted.
The implementations usually do (in the sense of optimizing them)
v8 only has 31-bit 'SMI' and not 32-bit ints, iirc.
Correct, but it is the only one to do so.
BigInt Shipping in Firefox
141–150 of 172 posts
Re: BigInt Shipping in Firefox
#142Earlier quoted context omitted.
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.
lua does the same thing. It's not crazy.
Re: BigInt Shipping in Firefox
#143Kind 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…
By that logic, you should also test if `a` is a string that can be parsed into a number/bigint as well. Or if it's a Uint8Array that you can decode into a number/bigint. But that's not how you write software. In an application, you have a canonical representation that you pass through your business logic.
> In an application, you have a canonical representation that you pass through your business logic.
Not if your code works with arbitrary inputs.
I have some collation sequences that I’ll need to tweak.
Re: BigInt Shipping in Firefox
#144Earlier quoted context omitted.
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.
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.
Re: BigInt Shipping in Firefox
#145Earlier quoted context omitted.
> 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: pyp…
25 nanoseconds is much longer than a normal double-precision addition, loop counter increment, and conditional jump back to the top of a loop should take, so there's something other than the time taken by additions that's going on in your benchmark. I'm not a Node.JS expert, but I suspect it's not getting JITted properly, or getting poorly optimized if so.
I tried in C:
#include
#include
int main()
{
double a = pow(2, 100);
for (double i = 0; i Re: BigInt Shipping in Firefox
#146Earlier quoted context omitted.
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.
Anybody who thinks that's actually good (or even real) advice is going to write horrible code regardless, IMHO.
Re: BigInt Shipping in Firefox
#147Earlier 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.
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.
Re: BigInt Shipping in Firefox
#148For context, more general browser compatibility: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe... In Chrome, but not Safari or Edge.
For those who care about JavaScript in embedded environments, Moddable released BigInt support in their open-source XS engine a few months ago: http://blog.moddable.com/blog/bigint/
Re: BigInt Shipping in Firefox
#149Earlier quoted context omitted.
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.
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.
Re: BigInt Shipping in Firefox
#150Kind 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…
It may be a good thing, for historical/backward-compatibility reasons.
But there's no reason that fixed-size ints and IEEE floats can't be intermixed with arbitrary-size/precision numbers, even in a small language, such as Scheme:
https://schemers.org/Documents/Standards/R5RS/HTML/r5rs-Z-H-...
Racket adds a bit more:
https://docs.racket-lang.org/reference/numbers.html
IIRC, Brendan Eich was aware of Scheme when he defined what's now known as JavaScript, but on a crazy-tight schedule, and JS wasn't intended to be an applications language.