A
Arthur J. O'Dwyer
The way I do it now is to save the whole tilebag. It would be nice to have
an integer that I could use to re-create the same game. I was working in
some kind of hash function. I thought the rand() function used the system
time or something to change each number, each time you called it. I'm a
little surprised it can be so predictable.
'rand' has to be predictable; otherwise, how could you ever test it
for correctness? Besides, the system timer is a notoriously bad way of
getting true random bits; if the C standard library seemed to bless it
in any way, that would just encourage bad security products. And Unix
(C's natural habitat takes its security *very* seriously.
If you want true randomness, there exist RNG servers for such
purposes, online. But then you can't use portable C to get online,
so it's OT either way.
A 16bit number would be OK, but maybe I should string a couple of rand()
generated numbers together.
Has anyone played with bitshifting and XOR'ing several rands to make them
more random, or perhaps XOR with the current time/date?
srand((unsigned)time(0)) is the "canonical" way to get a random seed
into the PRNG. Of course it's not secure, but it's good enough for
games and things that you won't ever need to run twice in close succession
expecting different outputs.
Something like put a rand() (15bit) into a 64bit number, shift a random
amount (<64bit), XOR or even "&" with another rand, loop again "X" times...
You are describing the "hashing" of a random number. This is the
second law of thermodynamics speaking: No matter how much you screw
around with a random variable, it's not gonna get any more random.
It can get *less* random, of course (shifting bits off the end will
lose those bits forever, e.g.), but you can't make randomness (a.k.a.
"information"; perversely, these are basically the same thing at the
information-theory level) from nothing.
Take further discussion of random numbers, security, and information
theory to one of comp.programming or sci.crypt, please.
-Arthur