On Saturday 04 June 2005 01:11, Philip Rowlands wrote: > Extend sort. In extending sort, would the O(n) shuffle algorithm be implemented? Or would the existing O(n log n) mergesort logic be used via keys?
Though I am not a sort maintainer, and am probably the least qualified to pass assumption or judgement, I would think that it might be harder to maintain two sets of processing paths in sort. Or, if we only use O(n log n) in sort, then that means there will always be a more efficient O(n) implementation elsewhere. Is that what we really want? It may be--I'll be the first to admit that for average cases less than several 100MB in size, the differences on modern 2ghz machines are almost unmeasurable. As far as some administrative trivia, I have applied for a shuffle project on savannah. I do not have a URL for source, an application requirement, so I'm not sure who the POC would be or how long it will take. shuffle itself has passed most unit tests. things to do on the horizon-- a) implement formal test procedures b) profile for memory leaks c) take an optimization pass and then it should be ready for primetime outside of coreutils. Of course, the final step d) Implement finite memory space architecture due to the work involved, is dependant on potential for coreutil admission. Thanks, Davis _______________________________________________ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
