Re: stable sort proposal

It seems like stable sort will be discussed in the 66th meeting of TC39. I hope for good news! https://github.com/tc39/agendas/blob/master/2018/09.md#agenda-items On 2018/09/12 12:02, kai zhu wrote: +1 it would avoid stable-sort workarounds like this [1], [2] for javascript-database

Re: stable sort proposal

+1 it would avoid stable-sort workarounds like this [1], [2] for javascript-database implementations. [1] testable, deterministic, stable-sort workaround for querying rows from db-lite https://github.com/kaizhu256/node-db-lite/blob/2018.4.23/lib.db.js#L1010

Re: stable sort proposal

`Array#sort` is stable in Chrome 70. https://twitter.com/mathias/status/1036626116654637057 All modern browsers (and IE 11) have stable sort with `Array#sort`. Would you like to mention `Array#sort` must be a stable sort on specification (>=ES2019)?

Re: stable sort proposal

Isiah Meadows wrote: A polyfill could check if `A.p.sort` is stable, replacing if necessary, and alias the old one to `A.p.fastSort` if it doesn't exist. How does one check/test for the stability of a black-box sort? You can't, afaik. In my opinion, you'll never be able to rely on the

Re: stable sort proposal

How about an `Array.prototype.stableSort(comparator?)` method? Several languages already have something like this, anyways. (Speaking of bugs related to unstable sorts, my blog has that problem as well - unstable sort resulting in incorrect order.) On Wed, Mar 16, 2016, 18:50 Tab Atkins Jr.

Re: stable sort proposal

Why should you have to opt into to stable sort? Why not the other way around? `Array.prototype.fastestSort` or some such -- or better yet, spec a symbol for it that falls back to `Array.prototype.sort` for implementations that don't expose a faster unstable variety. On Thu, Mar 17, 2016 at 7:35

Re: stable sort proposal

I'm mostly neutral on this, other than that a stable sort API should exist, and it shouldn't involve changing how the first argument of `Array.prototype.sort` is processed. On Thu, Mar 17, 2016, 22:20 Bergi wrote: > Isiah Meadows wrote: > > > A polyfill could check if

Re: stable sort proposal

On Tue, Mar 15, 2016 at 8:50 AM, Vic9 wrote: >> What about the Timsort? > > I cannot believe it will be faster on random int array. And TimSort is base > on MergeSort and, seems, for it's worst cases it cannot be better than > MergeSort. > I have tried

Re: stable sort proposal

On 03/18/2016 11:10, Tab Atkins Jr. wrote: If you're planning on pessimistically assuming that legacy implementations use an unstable sort for Array#sort(), then testing for the presence of Array#fastSort() (and assuming that when it appears the Array#sort is stable) is exactly as useful as

Re: stable sort proposal

On Fri, Mar 18, 2016 at 3:57 PM, Waldemar Horwat wrote: > On 03/18/2016 11:10, Tab Atkins Jr. wrote: >> >> If you're planning on pessimistically assuming that legacy >> implementations use an unstable sort for Array#sort(), then testing >> for the presence of Array#fastSort()

Re: stable sort proposal

> What about the Timsort? I cannot believe it will be faster on random int array. And TimSort is base on MergeSort and, seems, for it's worst cases it cannot be better than MergeSort. I have tried https://github.com/mziccard/node-timsort/ with my old node.js - 0.10.4 and Chrome 49 (win32) - and

Re: stable sort proposal

On Tue, Mar 15, 2016 at 12:00 AM, Vic9 wrote: > @Tab Atkins Jr., > > The only question is how much slower/more expensiver stable sorting is > than unstable sorting, and whether that cost is sufficient to outweigh the > usefulness of a stable sort. > My own experiment

Fwd: stable sort proposal

Missed the list... -- Forwarded message - From: Isiah Meadows <isiahmead...@gmail.com> Date: Tue, Mar 15, 2016, 07:42 Subject: Re: stable sort proposal To: Vic9 <vic99...@yandex.ru> What about the Timsort? It's used in Android's Java implementation, as well as

Re: stable sort proposal

Yeah...you got the intent, though. :) On Mon, Mar 14, 2016, 14:16 Tab Atkins Jr. wrote: > On Fri, Mar 11, 2016 at 8:17 PM, Isiah Meadows > wrote: > > In my honest opinion, there's not much reason to just require the sort > to be > > stable. Some

Re: stable sort proposal

@Tab Atkins Jr., The only question is how much slower/more expensiver stable sorting is than unstable sorting, and whether that cost is sufficient to outweigh the usefulness of a stable sort. My own experiment shows, that QuickSort (unstable) is ~20% (or more) faster on "random" array of

Re: stable sort proposal

On Mon, Mar 14, 2016 at 2:16 PM, Tab Atkins Jr. wrote: > On Fri, Mar 11, 2016 at 8:17 PM, Isiah Meadows > wrote: > > In my honest opinion, there's not much reason to just require the sort > to be > > stable. Some engines have done this in the past,

Re: stable sort proposal

On Fri, Mar 11, 2016 at 8:17 PM, Isiah Meadows wrote: > In my honest opinion, there's not much reason to just require the sort to be > stable. Some engines have done this in the past, and the spec technically > allows it. At this point, stable sorts are about as fast as

Re: stable sort proposal

>  `arr.indexOf(arguments[0]) - arr.indexOf(arguments[1])` This will work only if `arr` is a copy of an array which you are trying to sort, because the algorithm may swap those elements and so reposition them relative to other elements ... Stable sort is useful sometimes, but it is possible to

Re: stable sort proposal

In my honest opinion, there's not much reason to just require the sort to be stable. Some engines have done this in the past, and the spec technically allows it. At this point, stable sorts are about as fast as unstable ones, both in theory and practice (wasn't the case 10 years ago IIRC). On

stable sort proposal

EcmaScript hasn't have the stable sort method yet. http://www.ecma-international.org/ecma-262/6.0/#sec-array.prototype.sort Sure, we can create stable sort function by using `Array#sort`, by returning the number of index (e.g. `arr.indexOf(arguments[0]) - arr.indexOf(arguments[1])`) when it is