At 10:01 PM 10/10/2006, Tim Peters wrote:
>[Dick Moores]
> >>> Would this be a better random source than choice([0,1]), which uses
> >>> random()?
>
>[Tim Peters]
> >> "Better" as measured against what criteria?
>
>[Dick]
> > I meant would it be closer to true randomness than random(), even if
> > much slower?
>
>Define "closer to true randomness" ;-)
>
>I don't mean to be difficult, but if the phrase "cryptographically
>strong" doesn't mean something vital to you already, there's little
>for you to worry about here. If you want /true/ randomness, you can
>buy a certified hardware random number generator, based on
>non-deterministic physical processes (like timing radioactive decay,
>or measuring thermal noise).
>
>Anything short of that is more-or-less a hack designed to pass various
>tests for randomness. The Mersenne Twister is one of the best-tested
>generators in existence, producing a sequence indistinguishable from
>"truly random" via all tests in common use. Nevertheless, if an
>intelligent /adversary/ knows you're using the Mersenne Twister, they
>can exploit that under some conditions to predict the sequence you're
>using. OTOH, if you use a "cryptographically strong" generator, or a
>hardware source of true randomness, and your adversary knows that,
>current theory says that even if have they have enormous computer
>resources to throw at it, and you don't make "stupid mistakes" in the
>/way/ you use it, they won't be able to predict the sequence you're
>seeing at significantly better than chance rate.
>
>The /pragmatic/ answer to "would it be closer to true randomness?"
>thus depends on what you're trying to achieve. The theoretical answer
>is "yes", but that may be of no relevance to what you're trying to
>achieve.
>
> >> It's very much slower than using choice([0, 1]) (or choice("01"), or
> >> randrange(2), or ...), and can't (even in theory) be reproduced by setting
> >> a seed.
>
> > That's fine. Why would one want to?
>
>For example, any non-trivial program eventually grows a test suite to
>verify that the program continues to run correctly as time goes on.
>Testing a program that makes random decisions is, in general, very
>much easier if you have a way to force it to make the same decisions
>each time the test is run. For example, here's a tiny piece of
>Python's Lib/test/test_random.py:
>
> def test_genrandbits(self):
> # Verify cross-platform repeatability
> self.gen.seed(1234567)
> self.assertEqual(self.gen.getrandbits(100),
> 97904845777343510404718956115L)
>
>Without the ability to force the seed, that test wouldn't be possible.
> As is, it tests that given the specific seed 1234567, the next call
>to getrandbits(100) will return exactly 97904845777343510404718956115
>regardless of platform.
>
>Even if there is no test, non-trivial programs do "surprising" things
>at times. In a program that makes random decisions, if something
>/very/ surprising is seen, and you have no way to reproduce the
>decisions made before the surprising occurrence, you may be completely
>stuck in debugging it. OTOH, if there's a way to force the same
>decisions to be made, you can, e.g., run the program under a debugger
>to see everything that happens before disaster strikes.
OK, Tim, got it. Thanks for the education. My thanks also to the
others on this thread: Kent Johnson and Alan Gauld.
Dick Moores
_______________________________________________
Tutor maillist - Tutor@python.org
http://mail.python.org/mailman/listinfo/tutor
