> For working with huge files of data, mergesort is the best choice. > Saying you're going to beat it is nice - but it's like trying to > outswim a tuna - not likely in practice.
I don't believe this. Generally, when the data is partitioned small enough to fit into memory, it would be wise to then switch to quicksort if possible. So, i would agree with you that no one sort is best in this case, but it probably isn't correct to say merge sort is the best choice either. I agree that things have chnaged since my early tests of sorting. But, in those tests, Quicksort and then merging the sub-results was not as fast as simply mergesorting the data, straightaway. Memory has gotten a LOT bigger since then, so this may have changed the results - but I doubt it. Because HD's have become much faster as well. (Yellowfin Tuna swim about 45 m.p.h, top speed). Sharks don't outswim them, let alone humans. :-) Adak --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Algorithm Geeks" group. To post to this group, send email to algogeeks@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/algogeeks -~----------~----~----~----~------~----~------~--~---
