Hi Phil, Le 08/10/2014 02:38, Phil Steitz a écrit : > 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 > 1) improve initialization performance of the default RandomGenerator > 2) Replace the default with a generator with negligible > initialization latency > 3) Make either PRNG initialization or initialization of the > RandomGenerator field lazy > > I may have missed some. 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. 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). > > 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. 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. I would also > obviously be in favor or anything we can do in 1).
Having a default generator is not really something I am comfortable with. I consider the generator is really of the responsibility of the caller and not a low level library. In my use cases, I even create only one generator for a run and reuse it in all the classes that need a generator rather than building different ones: the reason for that is that it greatly simplifies initialization (only one seed) and that as some generators may have some latency to reach a steady state[1], I prefer to have one generator with more drawings extracted from it than several independent generators. So my preferences would be towards solution 0 for this specific case in the list you provide. A side effect is that I don't think the original patch to MATH-1154 should be applied. As is, this patch hides even more the generator, and while preserving the final field in the top class, it does so by moving it in another class. If the fact this field is final is a problem, then we should lift this restriction and do it in the open, rather than hiding our tracks from class to class. Another choice would be to simply document that if the user explicitly sets up a null generator, then sampling will fail. This is essentially what Thomas patch does if I understand it. I would even go further: either deprecate the constructors without random generator (and simply explain in the remaining constructors that this generator can be set to null if no sampling is desired), or lets this constructors but have them set the generator to null (and document it). I *hate* having these new Well19937c() calls hidden without user knowledge. Creating random generators without seed is really something we should avoid. Apart from that, improving performances of the WELL generators is certainly a good thing. Still another point would be to make random generators thread safe. It would be important in my use cases since I *do* share generators and it is intentional. best regards, Luc [1] the first few millions drawings are not as good as the later ones, see the paper on the WELL generator for examples > > Phil > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
