[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: new coreutil? shuffle - randomize file contents
From: |
Davis Houlton |
Subject: |
Re: new coreutil? shuffle - randomize file contents |
Date: |
Sat, 4 Jun 2005 08:18:18 +0000 |
User-agent: |
KMail/1.7.2 |
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
Re: new coreutil? shuffle - randomize file contents, Jim Meyering, 2005/06/02
Re: new coreutil? shuffle - randomize file contents, David Feuer, 2005/06/02
Re: new coreutil? shuffle - randomize file contents, David Feuer, 2005/06/02
Re: new coreutil? shuffle - randomize file contents, David Feuer, 2005/06/02