Re: Math.minmax

on tc39 criterias, this applies more to language-spec than library changes, but i think another criteria that can showstop stage 2-3 proposals is finding out whether a new syntax creates subtle engine de-optimizations that breaks the web. around mid-2016, i recall sites like github.com and

Re: Re: Math.minmax

Thank you for your answer Ben! I hope that TC39 will make the set of criteria clearer for a brighter futur. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss

Re: Re: Math.minmax

Thank you for your answer Ben! I hope that TC39 will make the set of criteria clearer for a bright futur. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss

Re: Re: Math.minmax

If you're reading on esdiscuss.org, that link got munged and I don't seem able to edit my posts anymore. Here's a shortened version: https://goo.gl/fioZmj -- T.J. ___ es-discuss mailing list es-discuss@mozilla.org

Re: Re: Math.minmax

On Mon, Oct 2, 2017 at 6:38 PM, Ben Newman wrote: > I would also challenge the committee to think about (or link to!) > any concrete written criteria that someone with an idea for a > proposal could use to assess its chances of acceptance. Imagine > how much time we

Re: Re: Math.minmax

```js const minMax = (arr=[]) => { if( arr.length==1 ) return [arr[0],arr[0]]; const result=[Infinity, -Infinity]; for( let i=0;i < arr.length;i++ ) { result[0] = arr[i] < result[0] ? arr[i]: ((result[1] = arr[i] > result[1]? arr[i]: result[1]), result[0]) ; } return result; }

Re: Math.minmax

Another important characteristic we look for in proposals is orthogonality: https://en.wikipedia.org/wiki/Orthogonality#Computer_science > On Oct 2, 2017, at 10:38 AM, Ben Newman wrote: > > Taking a step

Re: Re: Math.minmax

can I ask why nobody is using Math.min/max signature at their full potentials ? ```js const [min, max] = [ Math.min.apply(null, array), Math.max.apply(null, array) ]; ``` also, why are benchmarks using `Date.now()` instead of the more accurate `performance.now()` or the dedicated

Re: Re: Math.minmax

I would be curious about the reduce version that doesn't create a new object/array on every iteration: ```js const minMax = array.reduce( (accumulator, currentValue)=>{ accumulator.min = Math.min(currentValue, accumulator.min); accumulator.max =

Re: Re: Math.minmax

Taking a step back from the details of this proposal, I have some thoughts about why it seems to be struggling to find support. In no particular order, I would say this proposal - relies on microbenchmarks, which can be misleading

Re: Re: Math.minmax

JDecker: Just added your solution on the benchmark, it beats every others solution and it's a elegant solution. Kai Zhu: We can't see the screenshot. But please take in consideration that it's been a long time that ECMAScript isn't only used in webapp, and that some of applications using it can

Re: Re: Math.minmax

Ah yes, woods, I was looking at the trees. Still, to carry on with the concise style: ```js const minMax = (arr=[]) => arr.reduce( ([min=Infinity, max=-Infinity], curr) => [ min < curr ? min : curr, max > curr ? max : curr ], [] ) ``` On Mon, 2 Oct 2017 at 16:55 Xavier Stouder

Re: Re: Math.minmax

On Mon, Oct 2, 2017 at 8:49 AM, Xavier Stouder wrote: > No problem Boris, I edited this times a long time ago. > > Naveen, you missed he point. In fact, I just added your code the > benchmark (link aboce) and it has catastrophic performances. > Ya, that's a lot of array

Re: Re: Math.minmax

Same for Michael. Useless to not use a reducer instead of Math.min and Math.max if it has worth performance. Just to be clear, the fact is that your function approximately costs: Math.min: one loop over the array Math.max: one loop over the array Math.minMax: one loop over the array Math.minMax

Re: Re: Math.minmax

No problem Boris, I edited this times a long time ago. Naveen, you missed he point. In fact, I just added your code the benchmark (link aboce) and it has catastrophic performances. ___ es-discuss mailing list es-discuss@mozilla.org

Re: Math.minmax

Oh, and of course if I'm going to be that guy I should immediately post a slightly better version just to annoy people more: ```js const minMax = (arr=[]) => arr.reduce( ([ min=Infinity, max=-Infinity ], curr) => [ Math.min(curr, min), Math.max(curr, max) ], [] ) On Mon, 2 Oct 2017 at 16:44

Re: Math.minmax

I think your approach is fine, but just to be that guy I'll condense it some more (could be output as a hash but, if we're going to condense, well...): ```js const minMax = arr => arr.reduce( ([ min, max ], curr) => [ Math.min(curr, min), Math.max(curr, max) ], [ Infinity, -Infinity ] )

Re: Math.minmax

I would just use reduce for this. Reason: I think any multi var result format is a little messy. I find it better to let the dev decide on the result format, e.g.: ```js const minMax = array.reduce( (accumulator, currentValue)=>{ return { min:

Re: Math.minmax

On 10/2/17 7:10 AM, Xavier Stouder wrote: Don't know what Boris mean when he talks about recreation bits Fwiw, it looks like the code at https://esbench.com/bench/595c1b1899634800a03488b9 does not have the array recreation bits (function whatever(...args)) that earlier benchmarks for this

Re: Re: Math.minmax

As adviced by annevk on IRC, I'm gonna explains the results better. Minmax is more efficient that a min and a max : you loop one time instance of two. Seems logic. To not destructurate the array of arguments is of course better because at the end, by destructurating you're gonna work on an

Re: Re: Math.minmax

Doesn't performance matter? ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss

Re: Re: Math.minmax

Sorry for the delay! I just added some benchmarks, please tell me what you think about them! ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss

Re: Math.minmax

On 7/4/17 9:34 PM, Jordan Harband wrote: The results I get range from a 2x improvement for 2 numbers, to a 3x improvement for 1000 numbers Again, did you test without the array destructuring and recreation bits? I expect those dominate here, just like in the jsbench benchmarks posted

Re: Re: Math.minmax

The result is not so obvious on V8 (x0.9 on 2 numbers and x2 improvement for 1000 and 10 numbers). It would be helpful, for example, in the case of system monitoring. A friend of mine receives raw datas and he regularly needs to get min and max to handle those datas. He could do that

Re: Re: Math.minmax

Thanks, that's helpful. The results I get range from a 2x improvement for 2 numbers, to a 3x improvement for 1000 numbers (both 100K number examples get me a RangeError in Safari). What concrete use cases are possible with the performance of minmax that aren't possible with a separate min and

Re: Re: Math.minmax

You can run three tests here : https://esbench.com/bench/595c1b1899634800a03488b9 Running minMax polyfill and min max with two instructions on 2, 1000 or 10 numbers. ___ es-discuss mailing list es-discuss@mozilla.org

Re: Re: Math.minmax

To have that be worth a language change, I think you'd have to make a compelling argument that the performance of Math.min and Math.max, used together on the same large set of numbers, was sufficiently slow as to make widely used use cases untenable without your proposal. I'd be happy to review

Re: Re: Math.minmax

It's more concise and if you're comfortable with destructuring assignment syntax, I think it's also more readable. Whatever, differents folks, differents strokes. This proposal offer the possibility to reduce by two the length of a "get min and max" operation, and probably improve the

Re: Re: Math.minmax

To me it seems like minmax is *less* readable - between repeating the RHS (with min and max) vs condensing them and having nonobvious LHS syntax (with minmax), I'd prefer the current situation. On Tue, Jul 4, 2017 at 8:37 AM, Xavier Stouder wrote: > Even if I think it should

Re: Re: Math.minmax

Even if I think it should be a performance improvement, the main goal actually is to improve readability and conciseness of the code. When you say "I'd expect it to be something closer to [min, max] = Math.minMax(foo, bar)", are you saying that minmax (or minMax) should only take two arguments

Re: Re: Math.minmax

I'm honestly not convinced how this is actually useful. And also, just based on the name, I'd expect it to be something closer to `[min, max] = Math.minMax(foo, bar)`, which could effectively compile down for integers to up to two register `mov`s followed by a single `cmpxchggt` (compare and

Re: Re: Math.minmax

I just removed performance from goals of the proposal, given how it seems to depend about how min and max are called. Thanks for feedbacks. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss

Re: Math.minmax

On Fri, Jun 30, 2017 at 7:53 AM, Boris Zbarsky wrote: > On 6/29/17 1:49 AM, T.J. Crowder wrote: > >> I was going to make that very point, backed by a jsPerf, but the jsPerf >> doesn't back it up: https://jsperf.com/two-calls-vs-one-returning-array >> It says the minmax is

Re: Math.minmax

On 6/29/17 1:49 AM, T.J. Crowder wrote: I was going to make that very point, backed by a jsPerf, but the jsPerf doesn't back it up: https://jsperf.com/two-calls-vs-one-returning-array It says the minmax is faster on a 10-entry array (it reports the separate calls as 46-48% slower on V8 and

Re: Re: Math.minmax

The results is expected (in the naive way at least). You loop just one time instead of two on the array. Now I'm not enough involved in how JS engines work at a lower level to make more hypothesis. ___ es-discuss mailing list es-discuss@mozilla.org

Re: Math.minmax

A proper test would do this on a few hundred million elements interrupted every 16.6ms with a RAF so as to give the GC a chance to run and run about 30 seconds so as to trigger at least a couple GC cycles. On Thu, Jun 29, 2017 at 10:49 AM, T.J. Crowder < tj.crow...@farsightsoftware.com> wrote: >

Re: Math.minmax

On Thu, Jun 29, 2017 at 9:19 AM, Florian Bösch wrote: > > Improve performance > > I doubt that this sequence of calls: > > min = Math.min(min, value) > max = Math.max(max, value) > > > Is slower than this: > > [min,max] = Math.minmax([min,max,value]) > > Because while the former

Re: Math.minmax

> > >- Improve performance > > I doubt that this sequence of calls: min = Math.min(min, value) max = Math.max(max, value) Is slower than this: [min,max] = Math.minmax([min,max,value]) Because while the former can get inlined by JIT, the latter can't, and on top, it allocates 2 objects