Re: [PATCH] Makes sort create random order

[Paul Eggert]

Thomas Habets <address@hidden> writes:

> 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".

That is because ties are broken at the end by a last-resort textual
comparison.  Use "sort -s" to disable this.  For example:

   $ printf '3\n03\n3\n' | sort -ns
   3
   03
   3

> So what's your point? Are you refering to what would happen if you'd
> combine a -n sort with -R?

Yes.

> Or should a random permutation merge all equal values?

Only if the ordinary sort would merge the equal values (i.e., if the
-u option is specified).

> Does sort currently merge them, and are you saying the randomization
> has to be on the merged results?

Yes, I'm saying that randomization should be orthogonal to the other
options, and should work well and sensibly with them all.

> Can you give an example of permutaded input that does *not* give the same 
> output? ... if that is what you mean. (excluding randomization here)

Sure:

   $ printf '03\n3\n3\n' | sort -ns
   03
   3
   3

> 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?

Yes, that's what I was thinking of, given the same seed.

> why should they randomize to the same output just because they 
> have the same seed and are a permutation of eachother?

Because it's a sort program.  :-)

Seriously, though, I don't know how this new feature will combine with
all the other features of "sort", if it's not some type of feature
that can be explained as a sort.