Regarding implementing a stable sort for Phobos

Xinok xinok at live.com
Tue Mar 13 02:19:00 PDT 2012


On Tuesday, 13 March 2012 at 08:37:06 UTC, deadalnix wrote:
> I have a radix sort (that need some rework to be phobos 
> quality) and a smoothsort (that could be included in phobos).

Would you mind sharing your smoothsort? I haven't implemented one 
myself and I'd love to test it out.
Radix sort, on the other hand, is not a comparison sort. You'd 
have to rewrite it for every possible element and container type.

> I have a sort for ForwardRange, but it is O(n²) and unstable. 
> However, it is in place.

I posted one a few days ago myself - 
http://forum.dlang.org/thread/cmipnxrarexjgnrdqlvr@forum.dlang.org

> I don't think we should allocate behind one's back, so merge 
> sort should be an option, unless called explicitely.

When it comes to stable sorts, merge sort is the best choice. I 
found tree sort to be quite slow (using RedBlackTree in 
std.container), and a stable quick sort is still slower than a 
merge sort. So I guess that'd mean an in-place merge sort. I've 
implemented one which was 3x slower than quick sort. Allocating 
even a small amount of space makes a big difference.

> smoothsort is a good solution for that. radix is also guarantee 
> to be O(n). Insertionsort is quite risky, because it can ends 
> up in O(n²) very easily.


More information about the Digitalmars-d mailing list