Hi. Sorry: I had not seen your post before adding yet another unnecessary layer of comment to the JIRA issue for MATH-1154.
On Tue, 07 Oct 2014 17:38:34 -0700, Phil Steitz wrote:
Comments in MATH-1154 (bad performance in test code) and the now-reopened MATH-1124 (slow initialization) point to the need to fix the problem we created when we moved sample() to the distribution classes with PRNG provided by a final field with default implementation initialized by the constructor. Several suggestions have been made to improve things. 0) require that sample() take a RandomGenerator as an additional parameter
Looks fine. But not for 3.x release. Caveat: Not thread-safe.
1) improve initialization performance of the default RandomGenerator 2) Replace the default with a generator with negligible initialization latency
Both are worth doing, but do not address the issue, as there could always be use-cases where the initialization time, however small, will be too much, simply because it is not necessary. [This kind of argument was used for FastMath.] As long as initialization takes longer than whatever functionality is requested, this does won't fix issues similar to MATH-1154.
3) Make either PRNG initialization or initialization [lazy]
-1 We are talking of a low-level object; when a user intantiates a RNG, it is not usually expected that he has called a "dummy" constructor, and that actual work will be performed at some unspecified later time.
of the RandomGenerator field lazy
-0 I'd much prefer to leave the choice to the user, through his own selection of a "enhanced" RNG that _explicitly_ provides lazy intialization (cf. Otmar's proposal). See also below.
I may have missed some.
Yes: Otmar's proposal (part of the patch on MAH-1154 page).
One thing to note is that the (default) Well generators are *not* threadsafe, so having things final, avoiding lazy init is not really buying us anything in the current setup.
Thanks for bringing that up again.
So unless 2) is done with a threadsafe generator, only 0) really makes sample() threadsafe (assuming the caller protects the instance that needs to be re-supplied on each call).
Sort of... It would be nice to make the RNG implementation thread-safe. Or to know that some (all?) of them cannot be thread-safe, in principle. That would narrow the set of possibilities for a design that depends on the answer.
I am +0 for adding a new method that takes a generator as an additional actual parameter, but as a user I like the convenience of just calling sample(). I never use distributions as singletons, so the lack of threadsafety does not concern me.
Thread-safety is not only about singletons. Assuming that the RNG is thread-safe, the _same_ object can be used throughout an application's life-time, paying the initialization cost only once. [Which would in turn render the initialization bearable in many cases.]
It seems then that a reasonable approach might be to add the new method, keep the old one but move to lazy initialization with documentation that when you use the default, the provided PRNG it is not threadsafe.
With Otmar's feature, we get * lazy initialization (if needed) * backward compatibility * no API change Why should it be one or the other? Gilles
I would also obviously be in favor or anything we can do in 1). Phil
--------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
