Le 30 oct. 2013 à 04:54, Oliver Hunt a écrit :
> As currently specified Math.sign has 5 different return values and, as far as
> i can tell, does not solve the problem I thought it was trying to address.
> That is the difficulty in distinguishing positive and negative numbers
> without having
Unfortunately Claude, ES Math.sign is not Signum; it has five outputs, not
three, like Oliver was asking about. Observe:
> Math.sign(1 / 0)
1
> Math.sign(-1 / 0)
-1
> Math.sign(-1 / 0 * 0)
NaN
> Math.sign(0 * -1)
-0
> Math.sign(0 * 1)
0
Signum as specified in your link produces three outputs: 0,
On Tue, Oct 29, 2013 at 4:50 PM, Allen Wirfs-Brock
wrote:
> Spread now requires an Iterable rather than an array-like
This is different from how sequence behaves in IDL. (It uses array-likes.) :/
--
http://annevankesteren.nl/
___
es-discuss mailing l
Le 30 oct. 2013 à 11:44, K. Gadd a écrit :
> Unfortunately Claude, ES Math.sign is not Signum; it has five outputs, not
> three, like Oliver was asking about. Observe:
>
> > Math.sign(1 / 0)
> 1
> > Math.sign(-1 / 0)
> -1
> > Math.sign(-1 / 0 * 0)
> NaN
> > Math.sign(0 * -1)
> -0
> > Math.sign
Claude Pache wrote:
> `Math.sign` is expected to represent the mathematical sign
> function, which has a precise definition, see [1], [2].
> Please note that `+0` and `-0` are the same value as far as
> maths is concerned, and that value is neither positive nor
> negative. (Or both nonnegative and
Nathan Wall wrote:
> At the very least, I think Oliver has a point in that it'd be very
> useful to have a sign function which would return 1 for +0 and -1
> for -0. I've needed this in the past. If it shouldn't be `Math.sign`,
> perhaps there should be a `Number.sign` which would match the other
>
Hi,
There are algorithms that require 64-bit arithmetic, however currently
JavaScript does not provide any efficient way to perform it.
Similar to Math.imul which was added for the purposes of efficient
32-bit multiplication I propose extending Math object with a family of
operations Math.64 wher
On Oct 29, 2013, at 8:54 PM, Oliver Hunt wrote:
> As currently specified Math.sign has 5 different return values and, as far as
> i can tell, does not solve the problem I thought it was trying to address.
> That is the difficulty in distinguishing positive and negative numbers
> without having
> Rationale being faster polyfilled execution
The main reason for H being one shot is to allow optimizing compiler
*elide* updating it in most cases to eliminate memory traffic.
After thinking about it a bit I propose the following alternative step 5:
Math.H is from the very beggining a non-conf
2013/10/30 Vyacheslav Egorov
> 5. A one shot property Math.H is created that returns ch' on the first
> access and deletes itself.
>
Alternative step 5: Math.H is assigned ch'.
Rationale being faster polyfilled execution, in combination with a lack of
imagination from my side to come up with a
2013/10/30 Vyacheslav Egorov
> > Rationale being faster polyfilled execution
>
> The main reason for H being one shot is to allow optimizing compiler
> *elide* updating it in most cases to eliminate memory traffic.
>
Aaah. Thanks for pointing this out - I thought only of the polyfill
performance
Anne van Kesteren wrote:
OnTue, Oct 29, 2013 at 4:50 PM, Allen Wirfs-Brock
wrote:
> Spread now requires an Iterable rather than an array-like
This is different from how sequence behaves in IDL. (It uses array-likes.)
:/
This is more general, since array-likes should be iterable to be
On Wed, Oct 30, 2013 at 5:14 PM, Brendan Eich wrote:
> Anne van Kesteren wrote:
>> This is different from how sequence behaves in IDL. (It uses
>> array-likes.) :/
>
> This is more general, since array-likes should be iterable to be like
> arrays, which are iterable.
>
> So this seems ok. Right?
Anne van Kesteren wrote:
On Wed, Oct 30, 2013 at 5:14 PM, Brendan Eich wrote:
> Anne van Kesteren wrote:
>> This is different from how sequence behaves in IDL. (It uses
>> array-likes.) :/
>
> This is more general, since array-likes should be iterable to be like
> arrays, which are ite
Some people find "global" state that this proposal introduces bad. I
see two ways addressing this:
- Returning {lo, hi} object.
Pros: no global state, in combination with destructuring allows to
write concise code, overhead can still be optimized away.
Cons: performance of polyfill is abysmal on
On 10/30/13 7:57 AM, Anne van Kesteren wrote:
On Tue, Oct 29, 2013 at 4:50 PM, Allen Wirfs-Brock
wrote:
Spread now requires an Iterable rather than an array-like
This is different from how sequence behaves in IDL. (It uses array-likes.) :/
We could change that if we change all DOM arraylike
This is promoting a fix in the `Object.prototype` ... and since I believe
those dark days where `Object.prototype` shouldn't be touched due for/in
loops, I like it ^_^
Or maybe it's just a matter of `Arguments.prototype` , the most common non
iterable always converted via slice?
On Wed, Oct 30,
* are gone
On Wed, Oct 30, 2013 at 11:00 AM, Andrea Giammarchi <
andrea.giammar...@gmail.com> wrote:
> This is promoting a fix in the `Object.prototype` ... and since I believe
> those dark days where `Object.prototype` shouldn't be touched due for/in
> loops, I like it ^_^
>
> Or maybe it's jus
On Oct 30, 2013, at 10:51 AM, Boris Zbarsky wrote:
> On 10/30/13 7:57 AM, Anne van Kesteren wrote:
>> On Tue, Oct 29, 2013 at 4:50 PM, Allen Wirfs-Brock
>> wrote:
>>> Spread now requires an Iterable rather than an array-like
>>
>> This is different from how sequence behaves in IDL. (It uses
>>
On 10/30/13 2:28 PM, Allen Wirfs-Brock wrote:
All that is needed is to add an @@iterator method whose definition is
identical to
http://people.mozilla.org/~jorendorff/es6-draft.html#sec-array.prototype.values
Right. Pretty sure Gecko already ships just that (with a hack where we
use an actual
On Wed, Oct 30, 2013 at 7:01 PM, Boris Zbarsky wrote:
> On 10/30/13 2:28 PM, Allen Wirfs-Brock wrote:
>> Those are the sort of objects, that we decided to explicitly exclude
>> from spread and for-of.
>
> Sure. The question is whether we can compatibly exclude them from
> sequence in WebIDL. I e
On Oct 30, 2013, at 12:09 PM, Anne van Kesteren wrote:
> On Wed, Oct 30, 2013 at 7:01 PM, Boris Zbarsky wrote:
>> On 10/30/13 2:28 PM, Allen Wirfs-Brock wrote:
>>> Those are the sort of objects, that we decided to explicitly exclude
>>> from spread and for-of.
>>
>> Sure. The question is wheth
On Wed, Oct 30, 2013 at 7:23 PM, Allen Wirfs-Brock
wrote:
> Doesn't really depend upon the usage. If an API is going to return a
> sequence to JS code, it really should have an @@iterator. But that is
> presumably a non-breaking change, from the JS perspective. If an API wants
> to accept a
On Oct 30, 2013, at 12:29 PM, Anne van Kesteren wrote:
> On Wed, Oct 30, 2013 at 7:23 PM, Allen Wirfs-Brock
> wrote:
>> Doesn't really depend upon the usage. If an API is going to return a
>> sequence to JS code, it really should have an @@iterator. But that is
>> presumably a non-breaking c
On 10/30/13 3:23 PM, Allen Wirfs-Brock wrote:
If an API is going to return a sequence to JS code
Then it becomes a JS Array object in JS. So there is no change here.
If an API wants to accept a sequence it only needs it to have an @@iterator
if it is actually going to use JS iterator semant
Just to be sure, do you agree that both the {lo, hi}-returning API and the
magic-property API should both be able to achieve equivalent performance on a
JS engine that has specifically added and optimized these int64 builtins? I
think this is true.
Assuming so, the reason to prefer the rather
Yes, all API variants I have proposed should result in the equivalent
performance, to the best of my knowledge.
I would even say that {lo, hi} one is easier on VMs for two reasons:
- VMs tend to have some sort of escape analysis / allocation sinking
and they can incorporate { lo, hi } support int
On Oct 30, 2013, at 1:56 PM, Luke Wagner wrote:
> Just to be sure, do you agree that both the {lo, hi}-returning API and the
> magic-property API should both be able to achieve equivalent performance on a
> JS engine that has specifically added and optimized these int64 builtins? I
> think th
28 matches
Mail list logo
