random number generation: the newbie asks for advice

[Alex Martelli]

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