Rename Number.prototype.clz to Math.clz

classic Classic list List threaded Threaded
40 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Rename Number.prototype.clz to Math.clz

Jason Orendorff
ES6 adds a clz function, but it's a method of Number.prototype.clz
rather than Math.clz.

The rationale for this decision is here (search for clz in the page):
  http://esdiscuss.org/notes/2013-07-25

Can we reverse this, for users' sake? The pattern in ES1-5 is quite
strong: math functions go on the Math object.

The rationale (What if we add a uint64 type?) doesn't seem compelling
enough to justify the weirdness of the result: we'll have a single
mathematical operation available only as a Number method, and all
others available only as Math functions.

-j
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Rename Number.prototype.clz to Math.clz

Allen Wirfs-Brock

On Jan 15, 2014, at 11:18 AM, Jason Orendorff wrote:

> ES6 adds a clz function, but it's a method of Number.prototype.clz
> rather than Math.clz.
>
> The rationale for this decision is here (search for clz in the page):
>  http://esdiscuss.org/notes/2013-07-25
>
> Can we reverse this, for users' sake? The pattern in ES1-5 is quite
> strong: math functions go on the Math object.
>
> The rationale (What if we add a uint64 type?) doesn't seem compelling
> enough to justify the weirdness of the result: we'll have a single
> mathematical operation available only as a Number method, and all
> others available only as Math functions.

So we discussed all that when we made that decision.  I understand that you disagree but is there any new data that should cause us to reopen an issue that was already discussed and decided at a TC39 meeting?

Allen

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Rename Number.prototype.clz to Math.clz

Alex Kocharin
In reply to this post by Jason Orendorff

What if we add a uint64 type, we'd just have Math.clz64 (which is better than have X.clz returning something depending on a type, so you always have to check the type first)


15.01.2014, 23:18, "Jason Orendorff" <[hidden email]>:

> ES6 adds a clz function, but it's a method of Number.prototype.clz
> rather than Math.clz.
>
> The rationale for this decision is here (search for clz in the page):
>   http://esdiscuss.org/notes/2013-07-25
>
> Can we reverse this, for users' sake? The pattern in ES1-5 is quite
> strong: math functions go on the Math object.
>
> The rationale (What if we add a uint64 type?) doesn't seem compelling
> enough to justify the weirdness of the result: we'll have a single
> mathematical operation available only as a Number method, and all
> others available only as Math functions.
>
> -j
> _______________________________________________
> es-discuss mailing list
> [hidden email]
> https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Rename Number.prototype.clz to Math.clz

Brendan Eich-3
In reply to this post by Allen Wirfs-Brock
This is a judgment call, I'm with Jason, I think we should revisit. I'm
putting it on the TC39 meeting agenda.

/be

> Allen Wirfs-Brock <mailto:[hidden email]>
> January 15, 2014 11:26 AM
>
> So we discussed all that when we made that decision. I understand that
> you disagree but is there any new data that should cause us to reopen
> an issue that was already discussed and decided at a TC39 meeting?
>
> Allen
>
> _______________________________________________
> es-discuss mailing list
> [hidden email]
> https://mail.mozilla.org/listinfo/es-discuss
>
> Jason Orendorff <mailto:[hidden email]>
> January 15, 2014 11:18 AM
> ES6 adds a clz function, but it's a method of Number.prototype.clz
> rather than Math.clz.
>
> The rationale for this decision is here (search for clz in the page):
> http://esdiscuss.org/notes/2013-07-25
>
> Can we reverse this, for users' sake? The pattern in ES1-5 is quite
> strong: math functions go on the Math object.
>
> The rationale (What if we add a uint64 type?) doesn't seem compelling
> enough to justify the weirdness of the result: we'll have a single
> mathematical operation available only as a Number method, and all
> others available only as Math functions.
>
> -j
> _______________________________________________
> es-discuss mailing list
> [hidden email]
> https://mail.mozilla.org/listinfo/es-discuss
>
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Rename Number.prototype.clz to Math.clz

Jussi Kalliokoski
To me this sounds as a good idea, I was actually under the impression that it would be under Math until I saw the first ES6 draft featuring clz.

Having it under Math not only seems more consistent to me, but also lets you do nice things like `numbers.map(Math.clz)`.

Cheers,
Jussi

On Wed, Jan 15, 2014 at 11:08 PM, Brendan Eich <[hidden email]> wrote:
This is a judgment call, I'm with Jason, I think we should revisit. I'm putting it on the TC39 meeting agenda.

/be

Allen Wirfs-Brock <mailto:[hidden email]>
January 15, 2014 11:26 AM


So we discussed all that when we made that decision. I understand that you disagree but is there any new data that should cause us to reopen an issue that was already discussed and decided at a TC39 meeting?

Allen

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss

Jason Orendorff <mailto:[hidden email]>
January 15, 2014 11:18 AM

ES6 adds a clz function, but it's a method of Number.prototype.clz
rather than Math.clz.

The rationale for this decision is here (search for clz in the page):
http://esdiscuss.org/notes/2013-07-25

Can we reverse this, for users' sake? The pattern in ES1-5 is quite
strong: math functions go on the Math object.

The rationale (What if we add a uint64 type?) doesn't seem compelling
enough to justify the weirdness of the result: we'll have a single
mathematical operation available only as a Number method, and all
others available only as Math functions.

-j

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Rename Number.prototype.clz to Math.clz

Jason Orendorff
In reply to this post by Allen Wirfs-Brock
On Wed, Jan 15, 2014 at 1:26 PM, Allen Wirfs-Brock
<[hidden email]> wrote:
> So we discussed all that when we made that decision.  I understand that you disagree but is there any new data that should cause us to reopen an issue that was already discussed and decided at a TC39 meeting?

Well, here's one data point. This function, like most Math functions,
is particularly useful for systems that compile to JS, like
Emscripten. See <https://bugzilla.mozilla.org/show_bug.cgi?id=925123>.

Emscripten emits code (roughly) like this:

    function program() {
        var sin = Math.sin;
        ... lots of functions that call sin() ...
        return main;
    }

This kind of code has nice tamper-resistant semantics and (not
coincidentally) it will scream on existing JS engines.

If clz is a Math function, Emscripten can just

    var clz = Math.clz;

If it's a method, it would have to emit something like:

    var clz = Function.prototype.call.bind(Number.prototype.clz);

and hope the JS engines all optimize away the bound method call.

-j
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Rename Number.prototype.clz to Math.clz

Jason Orendorff
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.

-j
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Rename Number.prototype.clz to Math.clz

Mark S. Miller-2
On Thu, Jan 16, 2014 at 8:40 AM, Jason Orendorff <[hidden email]> 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.
 

-j
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss



--
    Cheers,
    --MarkM

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Rename Number.prototype.clz to Math.clz

Joshua Bell-2



On Thu, Jan 16, 2014 at 10:07 AM, Mark S. Miller <[hidden email]> wrote:
On Thu, Jan 16, 2014 at 8:40 AM, Jason Orendorff <[hidden email]> 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
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Rename Number.prototype.clz to Math.clz

Jens Nockert
In reply to this post by Jason Orendorff

On 2014/01/16, at 17:40, Jason Orendorff <[hidden email]> 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?
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Rename Number.prototype.clz to Math.clz

Mark Miller-2
In reply to this post by Joshua Bell-2



On Thu, Jan 16, 2014 at 12:09 PM, Joshua Bell <[hidden email]> wrote:



On Thu, Jan 16, 2014 at 10:07 AM, Mark S. Miller <[hidden email]> wrote:
On Thu, Jan 16, 2014 at 8:40 AM, Jason Orendorff <[hidden email]> 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?

Since the point is to make the answer have a mathematical relationship to the number denoted, rather than the limits of a particular representation, 53.
 

(If 53, environments trying to emulate 32-bit ints on top of Number could toss in yet another |0 or >>>0)

yes.
 

--
  Cheers,
  --MarkM

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Rename Number.prototype.clz to Math.clz

Mark Miller-2
In reply to this post by Jens Nockert
On Thu, Jan 16, 2014 at 1:12 PM, Jens Nockert <[hidden email]> wrote:

On 2014/01/16, at 17:40, Jason Orendorff <[hidden email]> 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

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Rename Number.prototype.clz to Math.clz

Kevin Reid-4
In reply to this post by Jens Nockert
On Thu, Jan 16, 2014 at 1:12 PM, Jens Nockert <[hidden email]> wrote:
On 2014/01/16, at 17:40, Jason Orendorff <[hidden email]> wrote:
> 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?

FWIW: Common Lisp has rigorously transparent (that is, you cannot observe the machine word size) bigints and quite a few binary operations defined on them, so it's where I personally would look for precedent on such questions. It doesn't have clz or bitlen per se, but it has these two functions which contain positions on the issue:

integer-length
Returns the number of bits needed to represent 'integer' in binary two's-complement format.
[Comment: This is equivalent to bitlen + 1 in order to count the sign bit, and is well-defined for negative numbers.]

logcount
Computes and returns the number of bits in the two's-complement binary representation of 'integer' that are `on' or `set'. If 'integer' is negative, the 0 bits are counted; otherwise, the 1 bits are counted.

(If I had guessed without actually reading the docs, though, I would have had logcount rejecting negative numbers.)

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Rename Number.prototype.clz to Math.clz

Mark S. Miller-2
Name aside, integer-length seems very sensible. For JS, I propose that it be extended to the remaining problem cases as follows:

f(-0.0) = f(0.0) = 0
f(-Infinity) = f(Infinity) = Infinity
f(NaN) = NaN

Why is logcount called "logcount"? As the doc on integer-length makes clear, it has a strong relation to the log-base-2 of the number. logcount does not.

What is logcount used for?



On Thu, Jan 16, 2014 at 1:41 PM, Kevin Reid <[hidden email]> wrote:
On Thu, Jan 16, 2014 at 1:12 PM, Jens Nockert <[hidden email]> wrote:
On 2014/01/16, at 17:40, Jason Orendorff <[hidden email]> wrote:
> 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?

FWIW: Common Lisp has rigorously transparent (that is, you cannot observe the machine word size) bigints and quite a few binary operations defined on them, so it's where I personally would look for precedent on such questions. It doesn't have clz or bitlen per se, but it has these two functions which contain positions on the issue:

integer-length
Returns the number of bits needed to represent 'integer' in binary two's-complement format.
[Comment: This is equivalent to bitlen + 1 in order to count the sign bit, and is well-defined for negative numbers.]

logcount
Computes and returns the number of bits in the two's-complement binary representation of 'integer' that are `on' or `set'. If 'integer' is negative, the 0 bits are counted; otherwise, the 1 bits are counted.

(If I had guessed without actually reading the docs, though, I would have had logcount rejecting negative numbers.)

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss




--
    Cheers,
    --MarkM

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Rename Number.prototype.clz to Math.clz

Brendan Eich-3
In reply to this post by Kevin Reid-4
Kevin Reid wrote:
> FWIW: Common Lisp has rigorously transparent (that is, you cannot
> observe the machine word size) bigints and quite a few binary
> operations defined on them, so it's where I personally would look for
> precedent on such questions.

(a) we don't have a bignum type yet; (b) we want to JIT to concrete
machine types where possible. (b) does not require clz32 vs. clz64 in my
view, because of type inference or AOT type-checking (asm.js). But we
don't want to require bignums.

/be
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Rename Number.prototype.clz to Math.clz

Jason Orendorff
In reply to this post by Mark S. Miller-2
On Thu, Jan 16, 2014 at 3:56 PM, Mark S. Miller <[hidden email]> wrote:
> What is logcount used for?

I think that's the same thing as "population count", which has a few
applications:

http://semipublic.comp-arch.net/wiki/Population_count_%28POPCNT%29

-j
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Rename Number.prototype.clz to Math.clz

Kevin Reid-4
In reply to this post by Brendan Eich-3
On Thu, Jan 16, 2014 at 1:58 PM, Brendan Eich <[hidden email]> wrote:
Kevin Reid wrote:
FWIW: Common Lisp has rigorously transparent (that is, you cannot observe the machine word size) bigints and quite a few binary operations defined on them, so it's where I personally would look for precedent on such questions.

(a) we don't have a bignum type yet; (b) we want to JIT to concrete machine types where possible. (b) does not require clz32 vs. clz64 in my view, because of type inference or AOT type-checking (asm.js). But we don't want to require bignums.

Yes, but choices which work for bignum also work for "I am working on 32-bit (or 8-bit or whatever) values which happen to be stored in a larger (53- or 64-bit) field, and the length of the larger field is irrelevant to the task".


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Rename Number.prototype.clz to Math.clz

Kevin Reid-4
In reply to this post by Mark S. Miller-2
On Thu, Jan 16, 2014 at 1:56 PM, Mark S. Miller <[hidden email]> wrote:
Why is logcount called "logcount"? As the doc on integer-length makes clear, it has a strong relation to the log-base-2 of the number. logcount does not.

Common Lisp calls most bitwise functions of integers log<something>, that's all.

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Rename Number.prototype.clz to Math.clz

Brendan Eich-3
In reply to this post by Kevin Reid-4
Kevin Reid wrote:

> On Thu, Jan 16, 2014 at 1:58 PM, Brendan Eich <[hidden email]
> <mailto:[hidden email]>> wrote:
>
>     Kevin Reid wrote:
>
>         FWIW: Common Lisp has rigorously transparent (that is, you
>         cannot observe the machine word size) bigints and quite a few
>         binary operations defined on them, so it's where I personally
>         would look for precedent on such questions.
>
>
>     (a) we don't have a bignum type yet; (b) we want to JIT to
>     concrete machine types where possible. (b) does not require clz32
>     vs. clz64 in my view, because of type inference or AOT
>     type-checking (asm.js). But we don't want to require bignums.
>
>
> Yes, but choices which work for bignum also work for "I am working on
> 32-bit (or 8-bit or whatever) values which happen to be stored in a
> larger (53- or 64-bit) field, and the length of the larger field is
> irrelevant to the task".

Agreed, for integral types.

I remember the Harbison & Steele C book, lots of Common Lispy names,
like population_count() ;-).

/be
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Rename Number.prototype.clz to Math.clz

Jason Orendorff
In reply to this post by Jens Nockert
On Thu, Jan 16, 2014 at 3:12 PM, Jens Nockert <[hidden email]> wrote:
> On 2014/01/16, at 17:40, Jason Orendorff <[hidden email]> wrote:
>> 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?

No opinion.

For the use cases I know of, speed matters: it is desired that this
operation compile down to a CLZ or equivalent machine instruction,
when the argument is in the range of uint32. I slightly prefer
Math.clz32 to Math.bitlen for this reason. It's exactly what it says
on the label. People searching for a JS equivalent of CLZ or
__builtin_clz() are likely to find it. The specification can start
with ToUint32 which already tells us how corner cases should behave.

-j
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
12