Subject: Re: [boost] [review] [sort] Sort library review manager results
From: Steven Ross (spreadsort_at_[hidden])
Date: 2014-11-28 07:55:07
> > I do not know if the review manager has a say in this but based on the
> remarks of the reviewers I would like to see the library as accepted be
> named 'SpreadSort' rather than just 'Sort'. I do think that Boost can have
> a library called 'Sort' but I agree with the general consensus that a
> 'Sort' library needs more than one type of sorting algorithm. I would like
> to see other people, who mentioned in the reviews/comments that they have
> their own sorting implementation, also submit their own implementations to
> Boost and, if this happens and they are accepted, I can see combining them
> with 'SpreadSort' into a general Boost sorting library called 'Sort' in the
> I think this is a very reasonable proposal.
> Regarding the possible future additions: I would absolutely love to
> submit my own sorting algorithm implementations. I first need to find
> time to remove a few rough edges before I would even dare to publish my
> code, but thank you for the encouragement. :-)
> One possible way to handle classic algorithms is to integrate them with
the tests I wrote for Spreadsort, and verify they show a significant
benefit relative to the existing libraries for some subset of realistic
cases and don't have any major bugs. Then a mini-review of the the API and
documentation might be appropriate. Here are some potential standard
algorithms that it might be nice to add in the future:
LSD radix sort, for fixed-length data where stability matters
Timsort, a stable comparison sort that is fast for mostly-sorted data and
is used by standard Java implementations.
A sorting network based comparison sort for small and fixed-size datasets.
I've found these to be about twice as fast as Insertionsort.
k-way merge parallel sort