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. Opinion? 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? Sean 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.