Qantas 94 Heavy wrote:
Would Math.clz32 still throw a TypeError if the argument is not a
number, nor an object with the [[NumberData]] internal slot? Currently
all math functions perform ToNumber on their arguments, unlike what
Number.prototype.clz is currently specified to do.
ToUint32 does
My bad, should have replied to all. Thanks for clarifying though.
On Fri, Jan 31, 2014 at 11:14 AM, Brendan Eich bren...@mozilla.com wrote:
Yes, that's right -- for type-inference-based JITs and AOT compilers that
use a type-checked subset (asm.js, e.g.) this is not an issue. And as you
Luke Wagner wrote:
It seems to me that we*must* have Math.clz perform ToUint32() on its input. Otherwise (if ToInt32()
is used), even if the expression is written Math.clz(x 0),
asm.js/type-inference won't be able to optimize away the0 branch since the ToInt32() in the
semantics
It seems to me that we *must* have Math.clz perform ToUint32() on its input.
Otherwise (if ToInt32() is used), even if the expression is written Math.clz(x
0), asm.js/type-inference won't be able to optimize away the 0 branch
since the ToInt32() in the semantics of Math.clz will convert
Nick Krempel wrote:
Whether log(0) is -Infinity or NaN should depend in some sense on what
side you approach 0 from (I arbitrarily claim to be approaching it
from the left in my formula, to give a NaN result there too).
I feel Math.log(-0) should be NaN in js for that reason, but it is
On 18 January 2014 18:16, Brendan Eich bren...@mozilla.com wrote:
Nick Krempel wrote:
Whether log(0) is -Infinity or NaN should depend in some sense on what
side you approach 0 from (I arbitrarily claim to be approaching it from the
left in my formula, to give a NaN result there too).
I
On 2014/01/17, at 4:20, Brendan Eich bren...@mozilla.com wrote:
Not sure it matters. We could return -1 for any negative number, 0 for 0, and
0 for positive integral values.
It does matter, this specific issue makes the x86 instruction BSR a lot less
useful than it could be. There they set
On Fri, Jan 17, 2014 at 6:12 AM, Jens Nockert j...@nockert.se wrote:
When I needed this function the last time (implementing audio codecs in JS) I
would have needed that it worked essentially like the bitwise operators, and
defined on the resulting 32-bit signed int.
Then you could write:
On 2014/01/17, at 13:24, Jason Orendorff jason.orendo...@gmail.com wrote:
Then you could write: Math.bitlen(x 0)
That would return 32 if x is a negative 32-bit signed int, because
0 converts ToUint32.
-j
Yeah, but when would I need to calculate it on a floating-point number?
Allowing
On Fri, Jan 17, 2014 at 7:07 AM, Jens Nockert j...@nockert.se wrote:
On 2014/01/17, at 13:24, Jason Orendorff jason.orendo...@gmail.com wrote:
Then you could write: Math.bitlen(x 0)
That would return 32 if x is a negative 32-bit signed int, because
0 converts ToUint32.
Yeah, but when
If you go with a representation-independent 'bitlen', I would suggest
returning NaN for any negative number.
This is consistent with a simple mathematical definition:
bitlen(n) := ceil(log_2(n + 1))
(Or, in js: Math.ceil(Math.log(n + 1) / Math.LN2), which potentially has
rounding errors, but
On H26/01/17, at 20:12, Nick Krempel ndkrem...@google.com wrote:
If you go with a representation-independent 'bitlen', I would suggest
returning NaN for any negative number.
infinity would make sense for a signed two's complement representation.
On 18 January 2014 06:25, Jason Orendorff jason.orendo...@gmail.com wrote:
Except I think we want bitlen(0) === 0 for consistency with clz.
Just noting that this actually works:
Math.ceil(Math.log(0 + 1) / Math.LN2) === 0
However:
Math.ceil(Math.log(-1 + 1) / Math.LN2) === -Infinity
Not
Adam Ahmed wrote:
Just noting that this actually works:
Math.ceil(Math.log(0 + 1) / Math.LN2) === 0
However:
Math.ceil(Math.log(-1 + 1) / Math.LN2) === -Infinity
That's pretty sweet, but then try -2 or -3 or below and you get NaN.
Not sure how that affects a Negative NaN-cy option :)
Whether log(0) is -Infinity or NaN should depend in some sense on what side
you approach 0 from (I arbitrarily claim to be approaching it from the left
in my formula, to give a NaN result there too).
I feel Math.log(-0) should be NaN in js for that reason, but it is defined
to be -Infinity in the
On 17 January 2014 19:25, Jens Nockert j...@nockert.se wrote:
On H26/01/17, at 20:12, Nick Krempel ndkrem...@google.com wrote:
If you go with a representation-independent 'bitlen', I would suggest
returning NaN for any negative number.
infinity would make sense for a signed two's
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
;
... 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
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
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
On 2014/01/16, at 17:40, 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
On Thu, Jan 16, 2014 at 12:09 PM, Joshua Bell jsb...@google.com wrote:
On Thu, Jan 16, 2014 at 10:07 AM, Mark S. Miller erig...@google.comwrote:
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
On Thu, Jan 16, 2014 at 1:12 PM, Jens Nockert j...@nockert.se wrote:
On 2014/01/16, at 17:40, 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
On Thu, Jan 16, 2014 at 1:12 PM, Jens Nockert j...@nockert.se wrote:
On 2014/01/16, at 17:40, Jason Orendorff jason.orendo...@gmail.com
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
On Thu, Jan 16, 2014 at 1:58 PM, Brendan Eich bren...@mozilla.com 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
On Thu, Jan 16, 2014 at 1:56 PM, Mark S. Miller erig...@google.com 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
Kevin Reid wrote:
On Thu, Jan 16, 2014 at 1:58 PM, Brendan Eich bren...@mozilla.com
mailto:bren...@mozilla.com 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
On Thu, Jan 16, 2014 at 3:12 PM, Jens Nockert j...@nockert.se wrote:
On 2014/01/16, at 17:40, Jason Orendorff jason.orendo...@gmail.com 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
Jason Orendorff wrote:
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.
Not sure it matters. We could return -1 for any negative number, 0 for
0, and 0 for positive integral values.
/be
would -0 return -1 too ? I could not resist asking for this, sorry!
On Thu, Jan 16, 2014 at 7:20 PM, Brendan Eich bren...@mozilla.com wrote:
Jason Orendorff wrote:
What is Math.bitlen(-1) then? Isn’t this just the same problem as
before, except it happens for negative numbers instead of
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 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
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
...@gmail.com
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
, 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
, 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
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
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
]:
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
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
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
]:
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
On Sun, Mar 4, 2012 at 6:44 PM, Allen Wirfs-Brock al...@wirfs-brock.comwrote:
I agree that there are useful functions when doing bit level decoding.
Luke has been championing the Math function additions for ES.next so he
should probably be the one to look at these specifically.
I assume
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
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
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
, 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
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
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
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
50 matches
Mail list logo
