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