Re: [PATCH] Makes sort create random order

[Thomas Habets]

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[]     = { "address@hidden" };
  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;