Viktor

Another option is just to have BigInt.min, BigInt.max

@jakobkummerow https://github.com/Yaffle/continuedFractionFactorization/blob/main/continuedFractionFactorization.js#L36 well... it can be implemented in user space ... but would be nice to have bitLength

@munrocket the second variant is finite, 0.1).toFixed(100) === 0.1000000000000000055511151231257827021181583404541015625000000000000000000000000000000000000000000000 (as the number can be represented as *2**, you can always multiply by power of 10 (to avoid negative exponent))

Another options is to allow BigDecimal.round to accept numbers and strings: BigDecimal.round(0.1, {maximumSignificantDigits: 15, roundingMode: 'half-up'}); // 0.1d BigDecimal.round(0.1, {maximumSignificantDigits: 1074, roundingMode: 'half-up'}) // 0.1000000000000000055511151231257827021181583404541015625d

https://gist.github.com/Yaffle/62addec7c78052ab72cc - merge sort - "slow", but stable

@nycos62 , if you know limits on the denominator and numerator , you can use method from https://stackoverflow.com/questions/14002113/how-to-simplify-a-decimal-into-the-smallest-possible-fraction/14011299#14011299 to convert decimal to fraction, then use fraction to string as @josdejong...

left shifting and right shifting operations should be in the code, unless missed in npm package also, there are BigInt.asUintN and BigInt.asIntN

btw, this project is not in active development, and I have no much interest in working on it. Native BigInt is much faster and has good browser support

when the code is transformed using babel-plugin-transform-bigint it uses JSBI, I want to replace JSBI with a wrapper around native BigInts as it native bigint implementation is faster. Another think,...