MASON-INTEREST-L Archives

June 2008

MASON-INTEREST-L@LISTSERV.GMU.EDU

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
Subject:
From:
Sean Luke <[log in to unmask]>
Reply To:
MASON Multiagent Simulation Toolkit <[log in to unmask]>
Date:
Thu, 26 Jun 2008 22:54:39 -0400
Content-Type:
text/plain
Parts/Attachments:
text/plain (44 lines)
On Jun 26, 2008, at 8:00 PM, Jim Saxe wrote:

> I'm wondering whether anybody knows a good way to use MASON for the
> rare event simulation technique known as "splitting".
>
> For those who don't know what this is, you can find references by
> doing a web search with the search terms "rare event simulation"
> and "splitting". Briefly, however, the technique involves
> identifying certain system states reached during a simulation--let's
> call them "split points"--from which it is desirable to run multiple
> continuations of the simulation with different random choices
> controlling the events after the split point in each continuation.
> Within each continuation, zero or more further split points might be
> chosen.

The obvious thing to do would be to clone the entire simulation, then
set some variable difference among them and continue. A couple of
issues arise:

1. Cloneable is problematic -- it doesn't work well if you have an
object graph: that is, for nearly any moderate sized scenario. For
this reason MASON was not set up to be deep-cloned in this fashion.
However there's another approach which WILL work, assuming you've not
created any non-final static variables (or have handled them
specially): serialize out the entire simulation, then unserialize
it. In fact you need not even create a file -- in ECJ we used
exactly this technique and created an object, ec.util.DataPipe (steal
it from the ECJ distro) to which you can attach an Input and an
Output stream.

2. There's the issue of correlation in the random number generators.
Though MersenneTwister is good, I don't get a good feeling there.
What I would do is replace the MersenneTwisterFast instances each
time you do a split with a brand new MersenneTwisterFast on a
different random number seed. Be very careful here -- you need that
seed to be really really random in order to avoid correlations. You
might use another high-quality generator to create a large stream of
ints, then grab each 624 (?) of them to populate a new MT instance's
internal state.

3. You'll need to handle output streams if you have them.

Sean

ATOM RSS1 RSS2