On Thu, Jan 16, 2014 at 10:07 AM, Mark S. Miller <erig...@google.com> wrote:
> On Thu, Jan 16, 2014 at 8:40 AM, Jason Orendorff < > jason.orendo...@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)
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
