Math.clz()

Jussi Kalliokoski jussi.kalliokoski at gmail.com
Sun Mar 4 12:30:50 PST 2012


On Sun, Mar 4, 2012 at 10:22 PM, Mark S. Miller <erights at google.com> wrote:

> It seems very strange to me to have a "clz" and "getOwnPropertyDescriptor"
> coexist as naming choices in the same language. I have taken to doing
>
>     var gopd = Object.getOwnPropertyDescriptor;
>
> early in many of my source files. I think this is better than
> standardizing an obscure acronym. This way, for every file that "clz" or
> "gopd" appears in, there's a declaration at the beginning stating the
> correspondence with a name whose meaning is easier to guess. This practice
> becomes even better supported by our new module system's
> import-with-renaming.
>
> Let's keep exported names clear. Let's abbreviate if necessary on import.
>

I sort of agree with this, although the JS1K devil in me is trying to fight
it.


>
>
> On Sun, Mar 4, 2012 at 1:38 AM, Jussi Kalliokoski <
> jussi.kalliokoski at gmail.com> wrote:
>
>> Bit.clz() sounds just as good to me. I don't know if they need to be less
>> cryptic, if someone doesn't know the abbreviation, it is highly likely
>> (s)he doesn't need the functions either. :)
>>
>>
>> On Sun, Mar 4, 2012 at 10:01 AM, Tomas Carnecky <tomc at caurea.org> wrote:
>>
>>> Wouldn't it be better to namespace these bit-operators in a different
>>> module?
>>> Bit.clz() perhaps? The Math module is getting a bit crowded.
>>>
>>> On Sat, 03 Mar 2012 23:21:11 -0800, Brendan Eich <brendan at mozilla.org>
>>> wrote:
>>> > I'm open to clz/clo. The names perhaps need to be less cryptic... or
>>> not.
>>> >
>>> > Allen should weigh in.
>>> >
>>> > /be
>>> >
>>> > Jussi Kalliokoski wrote:
>>> > > We're working on JS audio decoders, and one huge performance issue
>>> atm
>>> > > is clz() [count leading zeroes], which is a very commonly used
>>> > > algorithm in decoders. We've tried several different approaches and
>>> > > benchmarked them [1], however, different approaches work better on
>>> > > different engines, so optimizing the function is a bit of a no-go,
>>> > > especially if we want to have it fast in the future as well.
>>> > >
>>> > > So, I thought I'd propose something that would go well with the
>>> > > earlier proposals to extend Math [2]:
>>> > >
>>> > > Math.clz(number)
>>> > >
>>> > > This would allow for great speed boost in our decoders if it the JS
>>> > > engine had this built-in and optimized.
>>> > >
>>> > > While at it, it might be wise to add other related functions as well,
>>> > > such as clo (count leading ones), although not as useful.
>>> > >
>>> > > Cheers,
>>> > > Jussi
>>> > >
>>> > > [1]: http://jsperf.com/read-leading-zeros/8
>>> > > [2]:
>>> http://wiki.ecmascript.org/doku.php?id=harmony:more_math_functions
>>>
>>
>>
>> _______________________________________________
>> es-discuss mailing list
>> es-discuss at mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>>
>
>
> --
>     Cheers,
>     --MarkM
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20120304/98ae9f04/attachment-0001.html>


More information about the es-discuss mailing list