Rename Number.prototype.clz to Math.clz
jsbell at google.com
Thu Jan 16 12:09:16 PST 2014
On Thu, Jan 16, 2014 at 10:07 AM, Mark S. Miller <erights at google.com> wrote:
> On Thu, Jan 16, 2014 at 8:40 AM, Jason Orendorff <
> jason.orendorff at gmail.com> wrote:
>> At the risk of putting too many nails in the board...
>> The rationale seems to propose that (0).clz() === 32, but the
>> hypothetical uint64(0).clz() would return 64. That seems like a bad
>> idea though. It's weird for two zero values to get such different
>> behavior from the same method. It's weird for floating-point numbers
>> to have a clz() method in the first place.
>> Since these are two different mathematical functions, they should have
>> different names: Math.clz32(zero) would be 32 no matter what type of
>> zero you pass it; the hypothetical Math.clz64(zero) would of course be
>> 64. That way users can focus on the mathematical function being
>> computed, rather than runtime types.
>> Or maybe: flip the function around so that it returns the number of
>> bits in the binary expansion of the value: Math.bitlen(15) === 4. This
>> is just (32 - CLZ), so it effectively computes the same thing as clz.
>> The advantage is that it extends naturally to integers of any size.
> +1. I like this flipping idea by far the best. It can be explained in
> terms of the number being denoted, without referring to the internal
> limitations of any particular representation. With this change, I agree it
> should be a static on Math.
> With this flipped idea, let's think through what the proper .bitlen
> answers are for fractions, negative numbers, NaN, +/- Infinity, and -0.0.
Would Math.bitlen(Number.MAX_SAFE_INTEGER) return 53 or 32?
(If 53, environments trying to emulate 32-bit ints on top of Number could
toss in yet another |0 or >>>0)
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss