Path: utzoo!utgpu!utstat!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucbvax!pasteur!ames!amdcad!weitek!dms!albaugh
From: albaugh@dms.UUCP (Mike Albaugh)
Newsgroups: comp.lang.c
Subject: Re: How do I get random #s?
Message-ID: <619@dms.UUCP>
Date: 15 Feb 89 22:14:46 GMT
References: <5260010@hplsla.HP.COM>
Organization: Atari Games Inc., Milpitas, CA
Lines: 54


	I have exactly reversed the orrder of the following paragraphs,
to more naturally convey my comments/objections.
From article <5260010@hplsla.HP.COM>, by jima@hplsla.HP.COM (Jim Adcock):
> In summary, there's lots of simple, trivial, fast, but lousy
> ways to make random numbers in either hardware and/or software.
> Test what you would use.  Caveat Emptor.

	Agreed wholeheartedly, and I do _not_ wish to minimize this point!

> While, for many trivial applications, like playing games,
                  ^^^^^^^                    ^^^^^^^^^^^^^
> one may not care too much how good your random numbers
> are, but in many cases one needs to be able to assume
> the numbers really are "random" in order to be able to
> make reasonable statistical assumptions about whatever
> it is one's testing.

	Watch whose baby you call ugly ( :-) ). We (I) spend a great deal
of effort here on random number generation. We have some additional
constraints, because "really" random numbers tend to be viewed quite
skeptically by the general public. In general we try very hard to model
some actual physical (or psychological) system and use randomness only
where appropriate, deep within the model,rather than forming some gross
effect totally out of "random" numbers. This tends to ameliorate the
problem, but I wish to emphasize that if you need random numbers at all
you need good ones. How many of you would settle for a sin() that was,
well, sort of ok usually ?. (That many? :-) how about integer multiply?)

	Not to side _too_ completely with the original poster (lamenting
the lack of a "good" random number generator as part of the library). If
you know enough about your problem to wrap the right post-processing
around a good rand(), you probably know enough to write it from scratch
(with a finger in Knuth). If you don't, then what difference can the quality
of rand() make?

> For example, we frequently use random numbers to test software,
> using the random numbers to choose from the various commands that
> our software implements, with randomly selected parameters,
> in random order.  Its very nice to use this technique to 
> find software bugs, fix the bugs, then re-run the random command
> generator software with the same seed as a regression test.
> Can't do this with a combined hardware/software scheme.

	I would think that a better approach would be to generate the
whole stream ahead of time (with timings info as to _when_ commands
are entered), or to log it (again with timestamps) as it is generated.
Then a hardware, software, or "thousand monkeys" (software test group
of "naive users") method can be used at will, and re-play for regression
testing would be a snap.

	Yes, everybody, I agree this is getting rather far from comp.lang.c.
I promise to shut up now.
				Mike