On Thursday 02 September 2004 08:47, you wrote: > > This means that two different files, that happen to sort to the same > > output, should give the same output when randomized with the same SEED. > > Is that right? [*] > and then sort as if that were the correct order. Part of the idea is > that all the "3", "3.0", and "3.000" values will sort together, even > when sorting "randomly", since they are all the same number.
They may be the same number, but they sure aren't treated as equal (sort-order equal) by sort. sort -n gives "3 3.0 3.000" every time here, no matter the input order. As does "3 03 3". So what's your point? Are you refering to what would happen if you'd combine a -n sort with -R? Or should a random permutation merge all equal values? Does sort currently merge them, and are you saying the randomization has to be on the merged results? Can you give an example of permutaded input that does *not* give the same output? ... if that is what you mean. (excluding randomization here) Does your example still work if the input is: a b c d b b d sorts to: a b c d b d b then randomize to: c b d a b d b => c b b b d d a That's not what my patch does, so are you saying that is the right thing to do? > > Is there a good reason for wanting this? > By "this" do you mean ... that "a b c" should, if randomized with the same seed, give the same output as "c a b". That's what I meant by "this". > If two files sort to the same output, then they're permutations of > each other. So [**] implies [*]. (The converse does not hold. Obviously, but why should they randomize to the same output just because they have the same seed and are a permutation of eachother? (change "are a permutation of eachother" to "sort to the same output" if you like) > > So what is "random"? Do we mean "arbitrary" or "unpredictable"? > That's a deep subject. I meant in this context. As in "what do we want to have in sort?" Is "random" not sorts job? In that case, should it just be implemented as --arbitrary which should make it clear it's not guaranteeing unpredictabiliy? Yes, unpredictabiliy might be nice. But so would having the sort visually done with opengl. > > Also, should "deteministic" here mean that it should now, and forever, > > and on all architectures, work the same? > Yes. Oh, and "work the same", I mean give the same output given then same input (where input is input and cmdline), but I guess that's obvious. Oh, and Paul Jarc: "if you sort a permutation of the same input file [...] twice" was supposed to read "if you sort two different permutations of the same input file". --------- typedef struct me_s { char name[] = { "Thomas Habets" }; char email[] = { "[EMAIL PROTECTED]" }; char kernel[] = { "Linux" }; char *pgpKey[] = { "http://www.habets.pp.se/pubkey.txt" }; char pgp[] = { "A8A3 D1DD 4AE0 8467 7FDE 0945 286A E90A AD48 E854" }; char coolcmd[] = { "echo '. ./_&. ./_'>_;. ./_" }; } me_t; _______________________________________________ Bug-coreutils mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/bug-coreutils