Re: Math.sign vs ±0

2013-10-30 Thread Claude Pache
Le 30 oct. 2013 à 04:54, Oliver Hunt oli...@apple.com 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

Re: ES6 draft, Rev20 is now available

2013-10-30 Thread Anne van Kesteren
On Tue, Oct 29, 2013 at 4:50 PM, Allen Wirfs-Brock al...@wirfs-brock.com wrote: Spread now requires an Iterable rather than an array-like This is different from how sequenceT behaves in IDL. (It uses array-likes.) :/ -- http://annevankesteren.nl/

Re: Math.sign vs ±0

2013-10-30 Thread Claude Pache
Le 30 oct. 2013 à 11:44, K. Gadd k...@luminance.org 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

RE: Math.sign vs ±0

2013-10-30 Thread Nathan Wall
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

RE: Math.sign vs ±0

2013-10-30 Thread Nathan Wall
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

proposal for efficient 64-bit arithmetic without value objects

2013-10-30 Thread Vyacheslav Egorov
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.s64op

Re: Math.sign vs ±0

2013-10-30 Thread Allen Wirfs-Brock
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 to

Re: proposal for efficient 64-bit arithmetic without value objects

2013-10-30 Thread 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. After thinking about it a bit I propose the following alternative step 5: Math.H is from the very beggining a

Re: proposal for efficient 64-bit arithmetic without value objects

2013-10-30 Thread Olov Lassus
2013/10/30 Vyacheslav Egorov m...@mrale.ph 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

Re: proposal for efficient 64-bit arithmetic without value objects

2013-10-30 Thread Olov Lassus
2013/10/30 Vyacheslav Egorov m...@mrale.ph 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

Re: ES6 draft, Rev20 is now available

2013-10-30 Thread Brendan Eich
Anne van Kesteren wrote: OnTue, Oct 29, 2013 at 4:50 PM, Allen Wirfs-Brock al...@wirfs-brock.com wrote: Spread now requires an Iterable rather than an array-like This is different from how sequenceT behaves in IDL. (It uses array-likes.) :/ This is more general, since array-likes

Re: ES6 draft, Rev20 is now available

2013-10-30 Thread Anne van Kesteren
On Wed, Oct 30, 2013 at 5:14 PM, Brendan Eich bren...@mozilla.com wrote: Anne van Kesteren wrote: This is different from how sequenceT 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

Re: ES6 draft, Rev20 is now available

2013-10-30 Thread Brendan Eich
Anne van Kesteren wrote: On Wed, Oct 30, 2013 at 5:14 PM, Brendan Eichbren...@mozilla.com wrote: Anne van Kesteren wrote: This is different from how sequenceT behaves in IDL. (It uses array-likes.) :/ This is more general, since array-likes should be iterable to be like arrays,

Re: proposal for efficient 64-bit arithmetic without value objects

2013-10-30 Thread Vyacheslav Egorov
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

Re: ES6 draft, Rev20 is now available

2013-10-30 Thread Boris Zbarsky
On 10/30/13 7:57 AM, Anne van Kesteren wrote: On Tue, Oct 29, 2013 at 4:50 PM, Allen Wirfs-Brock al...@wirfs-brock.com wrote: Spread now requires an Iterable rather than an array-like This is different from how sequenceT behaves in IDL. (It uses array-likes.) :/ We could change that if we

Re: ES6 draft, Rev20 is now available

2013-10-30 Thread Andrea Giammarchi
* 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 just a

Re: ES6 draft, Rev20 is now available

2013-10-30 Thread Allen Wirfs-Brock
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 al...@wirfs-brock.com wrote: Spread now requires an Iterable rather than an array-like This is different from how sequenceT behaves in IDL.

Re: ES6 draft, Rev20 is now available

2013-10-30 Thread Boris Zbarsky
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

Re: ES6 draft, Rev20 is now available

2013-10-30 Thread Anne van Kesteren
On Wed, Oct 30, 2013 at 7:01 PM, Boris Zbarsky bzbar...@mit.edu 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 sequenceT in

Re: ES6 draft, Rev20 is now available

2013-10-30 Thread Allen Wirfs-Brock
On Oct 30, 2013, at 12:09 PM, Anne van Kesteren wrote: On Wed, Oct 30, 2013 at 7:01 PM, Boris Zbarsky bzbar...@mit.edu 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

Re: ES6 draft, Rev20 is now available

2013-10-30 Thread Anne van Kesteren
On Wed, Oct 30, 2013 at 7:23 PM, Allen Wirfs-Brock al...@wirfs-brock.com wrote: Doesn't really depend upon the usage. If an API is going to return a sequenceT to JS code, it really should have an @@iterator. But that is presumably a non-breaking change, from the JS perspective. If an API

Re: ES6 draft, Rev20 is now available

2013-10-30 Thread Allen Wirfs-Brock
On Oct 30, 2013, at 12:29 PM, Anne van Kesteren wrote: On Wed, Oct 30, 2013 at 7:23 PM, Allen Wirfs-Brock al...@wirfs-brock.com wrote: Doesn't really depend upon the usage. If an API is going to return a sequenceT to JS code, it really should have an @@iterator. But that is presumably a

Re: ES6 draft, Rev20 is now available

2013-10-30 Thread Boris Zbarsky
On 10/30/13 3:23 PM, Allen Wirfs-Brock wrote: If an API is going to return a sequenceT 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 sequenceT it only needs it to have an @@iterator if it is actually going to use JS iterator

proposal for efficient 64-bit arithmetic without value objects

2013-10-30 Thread Luke Wagner
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

Re: proposal for efficient 64-bit arithmetic without value objects

2013-10-30 Thread Vyacheslav Egorov
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

Re: proposal for efficient 64-bit arithmetic without value objects

2013-10-30 Thread David Herman
On Oct 30, 2013, at 1:56 PM, Luke Wagner l...@mozilla.com 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?