Hi.
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.
Regards,
Gilles
[...]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
