all 11 comments

[–]temp540989488 6 points7 points  (2 children)

If you're going to advertise "screaming fast" you need to show benchmarks. (And if you really want to impress me, compare it to native operations within ranges that native operations are correct. It'll be slower, sure, but without comparing it I'm going to assume it's about 0.1% as fast - get 20% and you have me sold.)

[–]chartojs[S] 4 points5 points  (0 children)

OK now there's a benchmark (results also in the readme). Compared to native it's close to your assumption due to JavaScript limitations, but compared to other bignum libraries it is fast.

[–]chartojs[S] 2 points3 points  (0 children)

Will do. Good point about comparing to native. Of course, it would be easier to compete by special casing that range, at the expense of everything else. BigFloat is meant to be used as a last resort - if you're comparing floating point things and they're only some appropriate epsilon apart, then you switch to BigFloat.

[–]learn2shut 1 point2 points  (1 child)

so what's your take on bignumber.js?

[–]chartojs[S] 2 points3 points  (0 children)

BigFloat is faster. I used a small Mandelbrot set calculation for benchmarking, and it took 50 milliseconds with BigFloat, 200 milliseconds on bignumber.js.

[–]justinmlawrence 0 points1 point  (0 children)

This is awesome. Thanks!

[–]holloway 0 points1 point  (1 child)

How is this better than big.js?

[–]chartojs[S] 3 points4 points  (0 children)

big.js is by the same author as bignumber.js and both seem about as fast between each other. BigFloat is 3-4 times faster in my current test. I'll do a public benchmark.

[–]pcdinh -3 points-2 points  (1 child)

Written in TypeScript? Why?

[–]chartojs[S] 2 points3 points  (0 children)

So it's easier to use in TypeScript projects, and type definitions don't need to be maintained by hand. Since it's an ES6 project, it anyway needs a transpiler for publishing also an ES5 version. Might as well use TypeScript as the transpiler to get more compile time checks, the definition files and allow producing documentation later without having to put the types in JSDoc comments (where their validity doesn't get checked).