BigInt log2
js-choi opened this issue · comments
@waldemarhorwat’s integer-roots implementation requires a log2 implementation, which he shims together using .toString().length. He notes regarding BigInt log2, “This should be a built-in.”
log2 is very useful for getting the bit length of a number. I think we might want to add BigInt log2 back to the proposal.
An alternative is to wait for a new bitLength function that supported BigInts but…why would we do that when we already could extend log2?
why would we do that
Maybe because bitLength would be an accurate name for the thing? The previously suggested Math.log2(bigint) wouldn't actually be a log2, it would be a rounded/truncated log2. Why should Math.log2(10n) be 3n when it could be 3.321928094887362? There's all this talk about avoiding loss of precision... but precision loss is inevitable for an actual log2 (even if the result is a Number). bitLength on the other hand does exactly what it says, with perfect precision.
(I also see no reason to assume that BigInt.bitLength would take any longer to spec and ship than Math.log2(bigint) -- on the contrary, as far as I'm concerned, I'd be happy to implement the former before the week is over because I consider it a very reasonable feature request, but I won't lift a finger in support of the latter because I consider it the worse option, for several reasons.)
Yes, I agree bigints should just have an accessor that provides this info, directly.
before the week is over
Actually, make that "before the day is over": https://chromium-review.googlesource.com/c/v8/v8/+/3755133
(This is BigInt.bitLength(bigint) (in the style of .asIntN); switching to BigInt.prototype.bitLength() (in the style of .toString) would be easy if there's consensus that that'd be preferable.)
It'd still need a proposal; I would expect either a prototype accessor (so 1n.bitLength worked) or the static method you've defined.
For what it’s worth, if people generally agree that bit length should be treated as a concept separate from log2 and unique to BigInts, then I’d be happy to champion a proposal-bigint-bit-length. I’ll close this issue later when I do so.
(Might it be better to make it a static function on BigInt to prevent boxing input BigInt primitives into BigInt objects? Also, should it return a number?)
@ljharb Of course it needs a proposal, and the patch won't land until there is one.
I just wanted to demonstrate that progress can be very quick when proposals are convincingly useful.
Might it be better to make it a static function on BigInt to prevent boxing input BigInt primitives into BigInt objects?
It currently is. But a prototype-installed method would be just as efficient. Really comes down to taste.
Also, should it return a number?
It currently does. Would be easy to change to a BigInt if desired. Again, comes down to taste. In particular, there are no Number range concerns: we cap BigInts to 1<<30 bits and have zero intention to ever raise that; Firefox caps to 1<<20 bits (or thereabouts) and that appears to be good enough.
@js-choi i'm quite confident accessing a method on a primitive doesn't actually produce the intermediate boxed primitive object, so i don't think that should be a concern.
I’ve created a proposal-bigint-bit-length repository, hopefully coming to Stage 1 later this year.