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 log2s 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.
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.
I’m taking a look at Yaffle’s poll, and it looks like several people have answered that they would find BigInt sqrt, cbrt, and log10 useful. I have been long wondering whether anyone would actually find these useful (they have been removed from the spec due to lack of use cases; the engines don’t want to implement anything without use cases), so it would be great if anyone could share their specific use cases for BigInt sqrt, cbrt, or log10.
(My current vision is that this initial proposal would overload only a few first Math methods, and that the initial proposal would open up the way to new proposals that would further extend Math with type-overloaded methods, like popcnt or modPow or bitLength (a truncating log2).)
log10 is useful for plotting on logarithmic scale, and string formatting. You may want to calculate something with BigInts and then show the result truncated to a number of significant digits.
edit: Well you could convert to string first and then truncate the string. But then you won't have proper rounding, unless you tinker with the string some more.
That being said, I would find it really weird if logN truncated the result to BigInt, instead of returning a Number. It would complicate the plotting on logarithmic scale use case. You'd basically need to first multiply by 1000 and then do the log10 to get a usable result.
edit 2: damn I'm dumb today. Multiplying of course wouldn't help at all, it would only add a constant to all results, but not make them "smoother". You'd need to pow like log10(x ** 20) to get a smoother plot.
It's num / (10 ** precision) mod a few edge cases. Logarithms simply count digits and aside from very large bignum arithmetic you can get away by just repeated division because the time it takes to do that is negligible compared to the cost of everything else and all you really need is a floored base 10 logarithm.
For bigints, as long as you have a "find first set" or related algorithm (like "count leading zeroes"), you can still do that part extremely efficiently.
This statement is wrong. The link is not even related; I assume you meant to instead link to this function in that code — notice how what it does is approximating log10(x).
When you have x = 10 ** 500, and want to print it in a readable form, you don't cut precision digits; you cut d = (log10(x) - precision) digits and append "E"+d. For example with precision = 5 the output would be "100000E495" (or some other form of the same, like "100000 * 10**495"). You may also cut trailing zeros, but you can only do that after cutting d excess digits, for which you need to know log10(x).
Repeated division is just a silly way of reimplementing logarithm. You could get fancy a use binary search to find the d, which is slightly more efficient and complicated way of reimplementing logarithm.
Yes, "find first set" would help reimplementing floored log10 more efficiently. "count leading zeros" only makes sense for fixed-width integers, not for BigInt.
Question is: why should everyone who wants to stringify large BigInts need to reimplement log10?
I'm aware, and was trying to implicitly acknowledge this in the comment you quoted.
Why I said "or related" - there's several ways of doing "find first set". Even something as simple as bit length would also be sufficient (and honestly, that's probably what I should've suggested in the first place).
I do get that concern, but I'm not convinced adding a decimal logarithm is worth it when that could just be addressed by adding .toPrecision to bigints to align with floating point numbers and suddenly nobody's having to roll their own stringifier.
There's of course other use cases, but I wouldn't consider them common by any stretch.
