Re: [boost] sorting library proposal (Was: Review Wizard Status Report for June 2009)o

Subject: Re: [boost] sorting library proposal (Was: Review Wizard Status Report for June 2009)o
From: Steven Ross (spreadsort_at_[hidden])
Date: 2009-06-03 12:05:30

On Wed, Jun 3, 2009 at 8:50 AM, Thomas Klimpel
<Thomas.Klimpel_at_[hidden]>wrote:

> I know that there are some geometry libraries currently under development
> that plan to be proposed for review sooner or later. At least one of them
> tries to address the robustness problems that occur in this context with a
> "novel" modification of an established technique. Should we tell the author
> that he has to publish these modifications first in a reputable journal
> before proposing his library for review? I don't think so. However, he will
> certainly have to convince the reviewers during the review that his
> implementation is reliable, which includes that the implemented algorithms
> are reliable.
>
> I also know that this case is different from the one currently discussed,
> in that this "novel" modification is an implementation detail of the
> geometry library, while the "novel" algorithmic improvements are an
> important motivation for proposing the "sorting" library for review.
>

string_sort would work okay without any novel modification from American
Flag Sort, but wouldn't be much faster than std::sort, due to the overhead
of its max/min checking.

I agree though, integer_sort and float_sort wouldn't be safe to use with any
other published algorithm I'm aware of due to poor worst-case performance
without the change to use std::sort, and increase of the fallback sort size
(is that really so novel?  Or just modernizing the algorithm?).  The
worst-case performance check is less essential once that step is taken, and
does nothing on 32-bit integers with current default settings.