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 performance. 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 < spam_from_boost_dev@chezphil.org> wrote:
I've added these static assertions in the casting methods:
BOOST_STATIC_ASSERT(sizeof(cast_type) == sizeof(data_type)); BOOST_STATIC_ASSERT(std::numeric_limits<data_type>::is_iec559); BOOST_STATIC_ASSERT(std::numeric_limits<cast_type>::is_integer); 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.