commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Gilles (Commented) (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (MATH-701) Seeding a default RNG
Date Thu, 03 Nov 2011 22:11:32 GMT

    [ https://issues.apache.org/jira/browse/MATH-701?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13143559#comment-13143559
] 

Gilles commented on MATH-701:
-----------------------------

IIRC we discarded the solution of passing a RNG in the distribution's constructor because
the "sample" methods was construed as syntactic sugar in order to access the "RandomData"
functionality from within the "...Distribution" classes.
It was also argued that people who would use this API (instead of directly instantiating a
"RandomDataImpl" object) would be satisfied with a default RNG, whatever was deemed the best
choice by the CM developers. Thus, if another generator is indeed better, we should just plug
it in instead of the current "JDKRandomGenerator".
In the same line of argument, the possibility of seeding was also supposed to be given up
in exchange for a "sample" API at the distribution level.

In "AbstractContinuousDistribution", we have:
{code}
protected final RandomDataImpl randomData = new RandomDataImpl();
{code}
In effect, there is no reason not to replace that statement with:
{code}
protected final RandomDataImpl randomData = new RandomDataImpl(new Well44497a());
{code}

As as side note: I don't understand why there is a default constructor in "RandomDataImpl";
since all the methods need a RNG, it does not make much sense to allow the object to be constructed
without one!

Second side note: Why not separate the "secure" alternatives into another implementation?
There would be "RandomData" (with a "nextHexString" method) and a "SecureRandomData" (also
with a "nextHexString" method, instead of the current "nextSecureHexString").

Back to this report's issue: The parent class "AbstractWell" seems to suffer from the same
problem because the default constructor calls {{System.currentTimeMillis()}}.
We should have a look at how "java.util.Random" seeds its default instances so that they can
claim (excerpt form Javadoc):
{noformat}
This constructor sets the seed of the random number generator to a value very likely to be
distinct from any other invocation of this constructor.
{noformat}

                
> Seeding a default RNG
> ---------------------
>
>                 Key: MATH-701
>                 URL: https://issues.apache.org/jira/browse/MATH-701
>             Project: Commons Math
>          Issue Type: Bug
>            Reporter: Gilles
>            Assignee: Gilles
>             Fix For: 3.0
>
>
> In "RandomDataImpl":
> {code}
> private RandomGenerator getRan() {
>     if (rand == null) {
>         rand = new JDKRandomGenerator();
>         rand.setSeed(System.currentTimeMillis());
>     }
>     return rand;
> }
> {code}
> The conditional branch is used by "sample()" in "AbstractContinuousDistribution".
> When several "...Distribution" objects are instantiated in a short time interval, they
are seeded with the same value.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

Mime
View raw message