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.