Okay, I'm fiddling around with an additional random number generator
store in the GUIState. It's a piece of cake to add and is entirely
backward-compatible. The only two demo applications that required
(very minor) changes were LightCycles and Flockers. Here's how I've
got it set up right now:
1. The random number generator is presently called "guirandom". I
could call it "random", which would be consistent with state.random,
but I'm worried it'd confuse people. Should I not be worried? Or can
anyone think of a better name? These variable names last forever.
2. The generator is created at GUIState construction time and is never
recreated thereafter (unless you want to do so yourself). I think
that's the proper strategy. It's presently just being created using
the current wall clock time, which should be sufficient I think.
3. One minor downside to not resetting the GUIState generator is that
every time you restart Flockers, even with the same seed, the colors
are different (of course). I presume this is fine?
On Aug 20, 2011, at 2:39 PM, Mike Little wrote:
> Sean -
> Here's one opinion: I see having distinct RNG's as illuminating
> rather than confusing, particularly if appropriately commented.
> It seems too often an RNG is viewed like a system service - just
> hook in if you want a random number. But this issue with the
> GUI illuminates that if you have a path in your program that
> may be non-deterministic - such as data communications, human
> interaction, input size, etc - and if that path also uses the same RNG
> as the rest of your otherwise deterministic experiment, inconsistency
> will occur. Further, I've encountered people who seem blocked on the
> concept of having multiple generators for multiple purposes. So
> having more than one in the sample code could be useful in that
> way, as well as preventing the issue Chris encountered.