[Ns-bugs] [Bug 101] random variable intialization

[code@nsnam.ece.gatech.edu]

https://www.nsnam.org/bugzilla/show_bug.cgi?id=101

--- Comment #16 from Michele Weigle <mweigle at cs.odu.edu> 2011-06-24 14:16:57 EDT ---
(In reply to comment #15)
> I am still skeptical that skipping any seeds is needed or worth the delay
> incurred.  I am not sure we are really preserving much of anything because
> presently, small perturbations in the scenario can cause lots of differences in
> the substream assignments.  However, I am willing to concede that point in the
> interest of getting this capability added; maybe I am not understanding the
> concern completely.

OK, if there's no concern about re-running regression/validation tests with a
new release, then there's no real need to skip streams.

> > One of the nice things about SetSeed is that you can set the seed for that
> > particular RV, but it doesn't affect the seeds coming from the default stream
> > (next_seed). So as long as you've jumped far enough ahead, you won't have any
> > interference issues.
> 
> I think you are referring to RngStream::SetSeeds() but I don't see how a user
> can call that from RandomVariable class.
> 
> Also, will use of SetSeeds() (different seeds for different RVs) affect the
> independence assumption between random variables?  For multiple independent
> replications, we have been recommending to SetSeed only once and advance run
> number only.

Actually, here's a different way.  Instead of saving the seeds and using
SetSeeds(), create and save some number of RngStream objects in a protected
streams array.  This would guarantee that the seeds are being generated in an
independent manner.  I think this could be done at the end of the if
(!initialized) conditional in RngStream::EnsureGlobalInitialized() -- after the
global seed and run have been set.

When a RandomVariable needs to use a protected stream, it could pass the
RngStream to the RandomVariable constructor.

When one of these protected streams is used by a RandomVariable, it could be
marked as 'used' so that another RandomVariable couldn't use it.   Maybe the
error message thrown (when a user tries to use an already used stream) could
indicate which of the protected streams are available for use in user-level
programs (if core code needs to use some of these as well).

This seems simpler than my previous suggestion.  Does it make sense to
everyone?

-- 
Configure bugmail: https://www.nsnam.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.