Mailing-List: contact dev-help@commons.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Commons Developers List" <dev@commons.apache.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8;
 format=flowed
Content-Transfer-Encoding: 8bit
Date: Fri, 07 Oct 2016 14:41:19 +0200
From: Gilles <gilles@harfang.homelinux.org>
To: <dev@commons.apache.org>
Subject: Re: [RNG] RNG-17 - LFG
In-Reply-To: <CAG3-T35w=ciB7ysmvKpFAiTX6-WDYG+xxJgoa1gYA46=SuZELg@mail.gmail.com>
References: <CAG3-T35w=ciB7ysmvKpFAiTX6-WDYG+xxJgoa1gYA46=SuZELg@mail.gmail.com>
Message-ID: <5a7f079503a5059674219f5764568ac8@scarlet.be>
User-Agent: Scarlet Webmail
X-DCC-scarlet.be-Metrics: hel; whitelist
X-Virus-Scanned: clamav-milter 0.98.1-exp at hel
X-Virus-Status: Clean
archived-at: Fri, 07 Oct 2016 12:41:31 -0000

Hello.

On Thu, 6 Oct 2016 18:20:24 +0300, Artem Barger wrote:
> Hi,
>
>
> I was considering​ to give a try and implement RNG-17
> <https://issues.apache.org/jira/browse/RNG-17> (LFG),

Fine.
But the Javadoc must then contain a warning akin to the one on
the Wikipedia page:
    Marsaglia observed very poor behavior with R(24,55) and smaller
    generators, and advised against using generators of this type
    altogether.
:-{

> while I'm complete a
> newbie in RNG topic.

Fortunately, one doesn't need to be an expert in order to port
a few lines of code from C (probably) to Java. :-)
But there are quite a few caveats.
That's why I've added those "contribution requirements"...

> So I've read a couple of tutorials and IMO I've got an
> idea behind the LFG (which doesn't seem that complex).

Most RNG are not complex.
What is complex is to find a _simple_ code that produces
sequences with the expected properties.
Even more so if those properties must be provable.

"Commons RNG" should not have the ambition to ship "home-made"
algorithms.
That's why I've added those "contribution requirements"...

>
> 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...

I'll open a JIRA ticket for that.

>
> Also I was thinking whenever it's could be beneficial to de-couple 
> seeding
> abstraction from actual number generation?

I don't follow (because I think that I did just that).
Could you give an example?

Regards,
Gilles

>
> Best regards,
>                       Artem Barger.


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org