 # GitHub - js-choi/proposal-bigint-math: Draft specification for supporting...

There is a proposal to make Math functions working with BigInts - GitHub - js-choi/proposal-bigint-math: Draft specification for supporting BigInts in JavaScript’s Ma . I am not the auther and cannot find any discussion, so I am creating this post.

Do you have use cases for one of the below functions?

• abs
• max
• min
• sign
• sqrt
• cbrt
• hypot
• log10
• log2
• one of other functions

0 voters

Would you like to have one of the below functions:

• bitLength
• nthRoot
• gcd
• modPow
• modInverse
• isPrime
• factorization
• random

0 voters

Note: bit length and log base 2 are essentially the same thing.

I do have use cases for a clz64, though.

1 Like

log2(x) can be different from bitLength(x) if to allow it to return floating point value... which can be useful sometimes (the current proposal, seems, wants to return bigint values, so you are right)

I think, clz can be computed from bitLength:
clz64(x) = 64 - bitLength(x), where x is a 64 bit bigint
clz128(x) = 128 - bitLength(x), where x is a 128 bit bigint

Technically yes, but how often are you to be computing non-floored `log2`s of large integers? Also, floats can't cover the entirety of the result space, so that limits its applicability, and non-integer results for integer input I believe are all transcendental anyways, so you're stuck with infinite decimals regardless.

I wouldn't be against using GitHub - tc39/proposal-decimal: Built-in decimal datatype in JavaScript to represent its return value, though. But using standard floats is a bad idea.

1 Like

A little excercise. Given

• `X: BigInt`
• such that `log2(X) > Number.MAX_VALUE`

What is the lower bound of:

• bitLength(X) >= ?

(and where do you store those bits)?

2 Likes

It would itself return a bigint, so that's not really a question. And bit length would just return the least amount of bits that could represent the bigint in question as a two's complement integer (i.e. one greater than the floored binary logarithm of that value).

Your argument was that floats can't cover the entirety of `log2`'s result space. I claim the practical (as in physically possible) result space is smaller than the range of double-precision float.

1 Like

I'd recommend stating that (with explanations of result ranges, etc.) as a bug against that repo, then. 