random number generation: the newbie asks for advice

[Ivan Frohne]

See http://starship.skyport.net/crew/statistics for an all-Python random number
generator.  Maybe it's fast enough -- try it out. Uniform random number algorithm
options include the Mersenne Twister, one from Knuth, and two other good ones -- all
much more 'random' than whrandom.

--Ivan Frohne 


Alex Martelli <Alex.Martelli at think3.com> wrote in message news:6D8A17398E28D3119F860090274DD7DB4B3D91 at pces.cadlab.it...
> I need a decent random number generator (the 24 bits of randomness 
> in the builtin whRandom are not enough), fast (probably needs to be
> written in C), whose state can be persisted and de-persisted.  The
> ranlibmodule in "Numeric" would seem to be almost perfect, except
> that it seems strange to make the whole "Numeric" a pre-req when I
> only use the random generation part, AND, the ran*.c files in the
> sources of Numeric leave me wondering -- how much can one trust
> in a C source file whose comments repeatedly say it's a Fortran 
> translation of a Pascal routine...?  (the sources do seem like some
> machine-translated Fortran, including 1-letter identifiers and goto
> as the main control structure).  It also seems to me that the C sources 
> are implementing a bazillion wonderful and exoteric generators which
> are not in fact exported -- making a larger .pyd to no benefit...?  Or
> trusting in linker's fine-grained optimization abilities...?
> 
> Is there a decent, Python-interfaced, C-written, stand-alone random
> number generator, with persistable/de-persistable state?  Or am I
> being too suspicious of ranlibmodule's quality and should just try to
> yank it out of "Numeric" for a smaller set of dependencies...?
> 
> Advice is welcome!
> 
> I would also welcome algorithmic advice on another somewhat
> related issue.  I need to shuffle 39 out of 52 cards, i.e., 13 of them,
> aka one "hand", are "pre-dealt"; I also need to guarantee that,
> if I generate two deal sequences with my algorithm, based on
> the same sequences of random numbers, such that the pre-dealt
> hands only differ by 1 card pair being "swapped", (say, in hand
> X there is a HJ and 12 other cards; in hand Y, the same 12
> other cards but the D8 instead of the HJ),  then each pair of deals
> in the two sequences will also only differ by that same swap.
> 
> (Hands are taken as sets, i.e. order of cards does not matter;
> the deal of the 39 non-pre-dealt cards is into 3 13-card piles,
> each also taken as a set of 13 cards).
> 
> It seems trivial, and I was _sure_ I had an algorithm with this
> property (it turns out I was wrong), but...
> 
> I can't come up with a general approach to ensure that, except,
> basically, by taking one pre-dealt hand as the "reference" one,
> and expressing every other in terms of changes to that one
> hand -- but then, I cannot find an "editing-change metric" that
> will ensure the above property for *any* pair of pre-dealt hands.
> 
> Again, any advice (or proof that it can't be done!-) will be
> most gratefully received -- TIA!
> 
> 
> Alex
> 
>