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 of
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 a
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
On Wed, Jan 15, 2014 at 1:26 PM, Allen Wirfs-Brock
al...@wirfs-brock.com 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?
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
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'
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 jason.orendo...@gmail.com:
ES6 adds a clz function, but it's a method of
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:al...@wirfs-brock.com
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
34 matches
Mail list logo
