Regarding implementing a stable sort for Phobos

Xinok xinok at live.com
Tue Mar 13 20:55:30 PDT 2012


On Tuesday, 13 March 2012 at 18:32:27 UTC, Xinok wrote:
> On Tuesday, 13 March 2012 at 06:32:01 UTC, Xinok wrote:
>> I've been playing with sorting algorithms a lot in recent 
>> months, so I want to implement a *working* stable sort for 
>> Phobos which is broken at the moment. I have a working library 
>> and I'm still adding to it. It's much more complex than a 
>> simple merge sort, being over 300 lines of code at the moment.
>
> I've implemented slicing which has improved benchmarks quite a 
> bit.
>
> It still uses O(log n log n) space. I modified the code to 
> allocate up to 1KiB on the stack, and use the heap for anything 
> larger. I simply marked the entry sort function as @trusted. 
> The non-slicing code is still in the lib but disabled. I've yet 
> to add contracts, documentation, and a unittest.
>
> I won't be adding optimized code for arrays utilizing pointers 
> as I expect the performance gain to be as little as 10%.

A second update:
http://www.mediafire.com/?gqejl17ob1ywyat

I removed the code without slicing from the lib, though I still 
retain a copy.
I added 3 unittests: A basic sort test, a stability test, and a 
CTFE test.
I added a few asserts which have helped me discover bugs in the 
past.
I only added basic documentation. I've found it difficult to 
explain to others how an in-place merge sort works, so I didn't 
bother.

I've ran the code through several tests. It works, it's stable, 
and it consistently gives good performance. So for the all 
important question: Does anybody want to implement it in 
std.algorithm for me? I've looked at the code in std.algorithm, 
and all I can tell is that sortImpl is a recursive function. I 
have no idea what it's doing or what I need to change.


More information about the Digitalmars-d mailing list