Re: When random isn't random
From: Jens Gruschel (nospam_at_pegtop.net)
Date: 12/14/03
- Next message: Richard: "Re: hex2ascii"
- Previous message: Peter Below (TeamB): "Re: DLL with string params callable via D4 and VB"
- In reply to: Dr John Stockton: "Re: When random isn't random"
- Next in thread: Sven Pran: "Shufle - was: When random isn't random"
- Reply: Sven Pran: "Shufle - was: When random isn't random"
- Reply: Dr John Stockton: "Re: When random isn't random"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Sun, 14 Dec 2003 12:40:46 +0100
> Efficient, reliable shuffling is not a special case of sorting. The
> behaviour of a sort with an inconsistent comparison function is
> essentially undefined; there may indeed be no guarantee of termination.
You are right.
> I do expect that many sorting methods will, with a random comparison
> function, give shuffled-looking results; but that is not good enough.
> For a shuffle, there must be a guarantee that, when using a perfect
> random number source, the probabilities of finding each item in any
> location must be identical, for a start.
So if you don't want to implement it with such a compare function (which
works, but - I agree - is some kind of hack), it shouldn't be too difficult
to write such a routine. Of course it would be nice to have such a ready to
use routine, but it probably will be difficult to offer all special wished
(you already mentioned that no item should be on its original position
afterwards, I can also think of: no item should be moved by more than some
delta).
Personally I think it would be more important to add Sort and Move methods
to collection classes, which don't have it (TCollection) and...
> A Sort Unit should provide other methods, including for arrays and other
> ordered structures.
...arrays.
> The best Sort for a probably-nearly-ordered set of
> data is not necessarily the one provided for sorting quasi-random data.
I agree. So I don't recommend to use a random comparison function any more,
sorry about that (especially if you plan to upgrade your applications to a
newer version of Delphi some day, which might implement another sort
algorithm, that doesn't support this hack any more). And I must admit, that
I never spent much time thinking about its efficiency.
> >There is. For example x' = (x * 1664525 + 1013904223) mod $100000000 can
be
> >undone by x = (4276115635 * (x' - 1013904223)) mod $100000000 (that's the
> >numbers I use in my own unit - see below)
>
> Not necessarily, AFAIK.
AFAIK all functions like x' = (a * x + b) mod m are reversible, if the
sequence contains all numbers in [0..m-1] (and I think in this case there is
exactly one inverse element of a). Of course that doesn't mean all random
number generators are reversable. And of course the greater m gets, the more
time-consuming it might be to find the inverse of a.
Jens
P.S. we move away from the original topic
- Next message: Richard: "Re: hex2ascii"
- Previous message: Peter Below (TeamB): "Re: DLL with string params callable via D4 and VB"
- In reply to: Dr John Stockton: "Re: When random isn't random"
- Next in thread: Sven Pran: "Shufle - was: When random isn't random"
- Reply: Sven Pran: "Shufle - was: When random isn't random"
- Reply: Dr John Stockton: "Re: When random isn't random"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|