I'm not sure I understood correctly, but... I think for the sake of this being a useful performance optimization, it shouldn't have any overloads / optional arguments, maybe a separate function for that is a better.
Also, while we are adding things to the Bit namespace, I'm not sure if ctz/cto (count trailing zeroes/ones) are really useful, I've never figured out a use case for them, but while at it, why not add it, might be useful in the future, although I highly doubt it. As for the string padding, it might be a bit redundant, but I don't know. On Sun, Mar 4, 2012 at 12:00 PM, Peter van der Zee <e...@qfox.nl> wrote: > Maybe make it generic? Although that might not be very important for > the case of counting leading zeroes or ones. > > I'd love a function for getting n consecutive bits (to left or > right..) from number x starting from the nth bith (from the left or > right) as a single number as if the lsb was 1. You can create masks > for this to & and >>, but it's not as versatile. Also, maybe a > toString function for binary with leading zero padding (or are we > getting String#pad now?). > > - peter > > On Sun, Mar 4, 2012 at 10:38 AM, Jussi Kalliokoski > <jussi.kallioko...@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 <t...@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 <bren...@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@mozilla.org > > https://mail.mozilla.org/listinfo/es-discuss > > >
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
