Subject: Re: [boost] Proposed templated integer_sort
From: Steven Ross (spreadsort_at_[hidden])
Date: 2009-02-02 22:50:21
I've uploaded a new algorithm_sorting.zip to www.boostpro.com/vault, which
resolves all the issues I found mentioned in past emails (tabs, data_type,
graphs, etc). I believe it contains everything necessary for a Boost
library at this point. Suggestion are welcome, as are performance results.
I'd particularly appreciate it if people could run tune.pl on their systems
and send me the output (tune.pl determines ideal constants).
I made my performance graphs on OSX. I have graphs of runtime vs. file
size, and other graphs of runtime vs. data range (0 to 32 bits). The data
range graphs are interesting, showing both the importance of MAX_SPLITS, and
how Spreadsort takes advantage of small ranges (clumpy data) for better
I've thought about Phil's enable_if suggestion more, and thought that it
might be possible to use a combination of my different algorithms to make a
spread_sort that first checks if an iterator's value_type is an integer, if
so, it uses integer_sort; otherwise it checks to see if it's a float, if so,
it sorts it with float_sort; finally it checks to see if it is a string, if
so, it sorts it with string_sort, and if not, it falls back on std::sort.
Does that sound like a useful generalization, or just an unwieldy mess? I
think most people know what they're sorting, but a generic spread_sort could
make generic programming a little easier.
On Mon, Feb 2, 2009 at 1:47 AM, Phil Endecott <
> I've added these static assertions in the casting methods:
>> BOOST_STATIC_ASSERT(sizeof(cast_type) == sizeof(data_type));
>> That should guarantee I'm casting an IEEE floating-point number to an
>> integer of the same size.
> I was imagining that you'd use these to enable a specialisation, e.g. using
> enable_if, rather than in asserts.