commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gilles <>
Subject [RNG] Initial state diversity (Was: ... RNG-17 - LFG)
Date Sat, 08 Oct 2016 07:04:29 GMT

On Fri, 07 Oct 2016 14:41:19 +0200, Gilles wrote:
> [...]
>> I haven't found in the literature the explanation of how to seed the 
>> LFG
>> though,
>> e.g. I have to create first "m" slots using the seed. However I've 
>> read in
>> some article, that Mersenne Twister could be used to seed the LFG. 
>> And here
>> comes my first question for you, is that  correct?
> Probably, but any procedure that produces a "sufficiently diverse"
> initial state would be fine.
> Such a procedure could be the output of another RNG.
> The "create" factory method does that (i.e. generates an array of
> length 128 filled with the output of a WELL generator) when no seed
> is provided.
> But the seed choice is a _user_ input so either
>  (1) he does not give one (and the "create" method does its thing,
>      as explained above), or
>  (2) he gives one with more elements than the state actually needs,
>      and the generator implementation should honor it (i.e. copy the
>      seed into the state) since we assume that the user wanted the
>      diversity of the seed he gave (no more, no less), or
>  (3) he gives one with less elements than the state actually needs,
>      and the implementation copies the seed to the state, and then
>      uses a procedure to replace the remaining zeroes in the state
>      with a more diverse contents based on the seed.
>> And second question I
>> was trying to understand how to reuse state initialization within 
>> current
>> Mersenne Twister for LFG?
> There is a public "fillState" method in "SeedFactory" for taking
> care of case (3) above.
> I must note that I made up a simple one (for use whenever the
> reference code did not provide that functionality).
> It's a matter of convention (for "Commons RNG") but we could well
> prefer to use the one provided by "MersenneTwister" (which has
> changed since its first version), to be on the safe side...

Having taken a look again, it turns out that there are
currently several different "filling" procedures:
  * one for MersenneTwister and  MersenneTwister64
  * one for the WELL generators
  * one for KISS and MWC256
  * one for XOrShift1024*

The MersenneTwister procedure also "scrambles" the whole
seed passed by the user; it thus does not do what is
described in (2) and (3) above.
It is very complex, probably to make it impossible to have a
"pathological" initial state (e.g. many zeroes).
Hence I don't think that it should be representative of what
all RNGs must do.

The "AbstractWell" class has a specific procedure that comply
with (3).  It is much simpler.

However, since it is part of the reference code, I find it
a bit fragile to transfer that code to "SeedFactory" and
assume that its "fillState" implementation would be forever
tied to a specific RNG.

I thus think that an approach could be to modify "fillState"
so that it has all the "ingredients" of the WELL method.

I will also create a overloaded version (for "XOrShift1024*").

Any objection?

> I'll open a JIRA ticket for that.


>> [...]

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message