[Ns-developers] ns-2/3 RNG

[Tom Henderson]

Michele Weigle wrote:
> On Dec 19, 2005, at 2:49 AM, Mathieu Lacage wrote:
> 
>>> As far as what GSL offers over what we have now, there are a  number of
>>> random variable distributions that are included with GSL that I don't
>>> think are implemented in ns (Weibull, for instance).  But, I think  
>>> that we
>>
>>
>> The distributions I use are:
>>   - uniform
>>   - binomial_pdf
>>
>>> can add those distributions as people need them without too much  
>>> trouble.
> 
> 
>> From an engineering point of view, using a debugged existing  solution is
>> clearly much better than relying on an hypothetical non-existing non-
>> debugged solution. If some of the things we need are not there, I  see no
>> point in trying to re-invent the wheel: this seems like a waste of
>> time/energy/ressources. Of course, these are your ressources/energy/ time
>> so, I don't really care that much about them but it feels like a  shame.
>>
>> I think whether or not to have an internally-maintained rng generator
>> should be decided not on features alone. There are good reasons to  drop
>> or keep the generator which do not involve its feature set:
>>
>>  - keeping an internal rng generator is costly because it means  that we
>> have to maintain it. The fact that you do maintain it today is not
>> really relevant because, you will eventually get interested in other
>> things and will, one day, leave this code to be maintained by someone
>> else.
>>
>>  - keeping an internal rng generator is good because it ensures:
>>       - the same results on different platforms
>>       - easy porting between different platforms
>>
>>  - using a well-maintained external portable rng generator is good
>> because it ensures:
>>       - the same results on different platforms
>>       - easy porting between different platforms
>>
>> It seems to me that the choice here is not clear cut. I would favor
>> giving up on the current internally-maintained rng generator if a  well-
>> maintained portable alternative can be found. gsl might be a candidate
>> but I have not investigated its port status to win32 and osx.
> 
> 
> It could be that GSL is what we want to use, but I wasn't able to  
> quickly find a way to address your #1 requirement:
> 
>>> 1) ability to create multiple random number generator instances which
>>> will not generate the same random number series during a single  run of
>>> the simulator.
> 
> 
> Just from quickly looking at things in GSL, it seemed that if you  
> created a new RNG, it would be seeded to the default (which is the  same 
> as every other RNG you create).  If there was some "next- substream" 
> equivalent and a guarantee that new RNGs were  automatically seeded 
> appropriately, then I don't really see a problem  with moving to GSL.  
> But, I don't want to move just for the sake of  maintainability if we 
> lose this important feature.
> 
> -Michele
> 

Did we reach a conclusion on this thread?  Is the answer for now to keep 
things as they are, with Michele possibly cleaning up the interface in 
the future and providing a C++-only interface?

I think that Mathieu's suggestion of putting this into a library and 
writing a wrapper allowing substitution of different rng might be the 
way to go with ns-3, if someone wants to tackle that.

Tom