Rename Number.prototype.clz to Math.clz
Mark Miller
erights at gmail.com
Thu Jan 16 13:31:11 PST 2014
On Thu, Jan 16, 2014 at 1:12 PM, Jens Nockert <jens at nockert.se> wrote:
>
> On 2014/01/16, at 17:40, 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.
>
> What is Math.bitlen(-1) then? Isn’t this just the same problem as before,
> except it happens for negative numbers instead of positive?
>
Good question. I don't yet have an opinion. But for a baseline, for all the
problem cases (fractions, negative numbers, NaN, +/- Infinity, and -0.0),
what would .clz have done?
--
Cheers,
--MarkM
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20140116/7c2f2de3/attachment.html>
More information about the es-discuss
mailing list