August 2011


Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Sean Luke <[log in to unmask]>
Reply To:
MASON Multiagent Simulation Toolkit <[log in to unmask]>
Sat, 20 Aug 2011 17:31:26 -0400
text/plain (40 lines)
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.