Optimizing Java using D
Andrei Alexandrescu via Digitalmars-d
digitalmars-d at puremagic.com
Mon Jun 23 10:25:13 PDT 2014
On 6/23/14, 9:33 AM, Chris Cain wrote:
> Or, to look at it another way, all "stable" sorts satisfy the qualities
> needed by an "unstable" sort, but not all "unstable" sorts satisfy the
> qualities of a "stable" sort. The minimum number of swaps/operations to
> create a sorted array won't necessarily maintain the stability property
> of the elements.
Yeah, it's really simple: the set of unstable sorting algorithms
includes the set of stable sorting algorithms, so unstable sorting is
vacuously "at least as good or better".
I'm baffled by the recurrent assertion that stable sort algorithms are
somehow faster than unstable sort algorithms.
First, comparing entire sets of algorithms on unspecified input
statistics is tenuous. A comparison would be between specific algorithms
on specific data statistics.
Second, there are known reasons and setups where Timsort and derivatives
fare better than classic quicksort-based implementations, and
generalizing them into some magic "stable sort is just better" umbrella
argument is just odd. Timsort works well on data with large continuous
sorted runs, and that's an important case but one that a quicksort-based
approach could and should avail itself of as well.
Third, again, anything stable is also unstable :o).
Andrei
More information about the Digitalmars-d
mailing list