Politness Costs Nothing but Can Pay Dividends

[Aeson]

If you need a random number just roll some dice, okay?

Having seen several lotto stations here that have no computers whatsoever, I think you're probably closer to the truth than the rest of them...

[Cort Haus]

This is all very dull. Surely the thing to use is a Brambleweeny57 sub-meson brain linked to an atomic vector plotter suspended in a nice hot cup of tea.

[Cort Haus]

Hmm, perhaps Douglas Adams should have used a molecular vector plotter instead.

[C0ckney]

This has got to be the most boring argument that I've ever read. This is time that I'll never get back. That's just great.

isn't it just. i'm never starting another thread here.

[Asher]

No, Asher, I am not "extrapolating" anything here. What I am saying is that reseeding can (and does) create undefined behavior. Drawing from a single stream as long as possible is the best solution here, because it guarantees the independence (measured through a large set of statistical tests) of different lotto tickets put out by these machines.

If you knew how RNGs were built you would know that.

Never send a tech guy to do a quant's job.

Using the same stream doesn't guarantee independence, using a new seed does.

The numbers in a stream are derived from a seed. There is a word for that: dependence.

[Asher]

I'm sure in the very high-end RNGs with lots of compute resources, they "try very hard" to make the "random" stream look random. But I assure you, they do not try very hard on low-end devices with tight RAM and CPU constraints.

[Asher]

I'm still curious why exactly you think re-seeding would be a problem for lotto terminals. If you re-seed it with a new seed between users (eg, time in ns or instruction counter value from the CPU), how is this any more or less random? You get a new seed, you get a new stream of numbers.

I understand in more complex RNGs like the ones you probably used in grad school/work, the stream will be generated in a more "well-defined" way because the process is probably quite resource intensive. On embedded systems, they don't have that. They've simple "random" number generators whose stream results are not that random at all. Again, look at Shuffle on the iPod and tell me you think it's very random.

Java even has two RNGs to choose from: java.util.Random and java.security.SecureRandom -- guess which one generates more random streams than the other? Guess which one is more resource intensive by orders of magnitude?