On 11/16/10 4:16 PM, Luc Maisonobe wrote:
Hi all,
Some of our algorithms do use random number generation. I quickly
reviewed them and found different ways to use them.
Genetic algorithm use a single static RandomGenerator shared by all
instances. It default to JDKRandomGenerator and can be reset by calling
setRandomGenerator.
The shared static was for reproducibility of results. The setup is a
little awkward there (as noted in the comments to MATH-207). The
sharing needed is really within a single full "instance" of the
framework. Different classes instantiated by the GeneticAlgorithm
need to be able to share a source of randomness if reproducible
results are desired. I would see this as an exceptional case and
welcome suggestions on how to remove the smell here without
polluting the API.
+1 for ditching JDKRandomGenerator for a better default
+1 for uniformly making RandomGenerator the type of the configured
entity (as it is in GA)
Multi-start optimizers use a separate RandomGenerator for each instance,
set by a constructor argument.
In general, I like this the best, though in some cases setters may
also be useful.
NaturalRanking use either a RandomDataImpl which is itself either based
on a RandomGenerator constructor argument or a JDKRandomGenerator by
default if the user did not provide a generator.
This is fine, IMO, but we should change the default. The publicly
exposed thing to configure is a RandomGenerator.
Kmeans++ use directly a java.util.Random instance provided as a
constructor argument (only this class can be used, none of our
generators can be used here).
This should be changed to a RandomGenerator, which will allow our
generators to be plugged in (the reason that RandomGenerator exists :)
What about changing this to be more consistent ? I would like to have
all our algorithms use the RandomGenerator interface, thus allowing the
user to put the generator more suited to their needs (it can be the JDK
one or a better one like Mersenne-Twister or one of the WELL
generators). I would also like to have one generator for each instance
set up at construction time. I also think JDKRandomGenerator is probably
not a good default and one of the more modern generators we now have
could be used like Well19937c.
I like Ted's ideas on making it easier to fix seeds for the tests.
Phil
Luc
---------------------------------------------------------------------
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
