On Tue, 27 Sep 2016 00:37:26 +0200, Emmanuel Bourg wrote:
Le 26/09/2016 à 18:33, Gilles a écrit :
As I suggested previously on this list, I'm going to request
a new "git" repository for implementing utilities based on
random generators.
I suggest waiting until RNG 1.0 is out and we have a clearer view of
the
scope of the components. We can still experiment with "rng-tools" on
a
separate branch or with a Maven module in the same repository.
My point is that we don't have a clear view.
An additional module in Commons RNG will not help, as was noticed
some time ago: it won't be possible/allowed to release the modules
separately.
I don't want to have to release a major version of Commons RNG
just because accessory tools requires it.
Users should not wonder with each new version whether there was
a bug or a change in the core functionality.
Morevover, as an example, you don't seem to like my choice of
factory. Adding layers and tools in the same component will
multiply the discussions about taste and mileage to no end.
As there was in CM. As it happens now.
Another git repository will avoid that temptation.
First candidates are:
* Non-uniform deviates (i.e. the samplers now defined in
Commons Math's "o.a.c.math4.distribution" package),
I agree this doesn't belong to commons-rng, but I'm not convinced it
would fit a commons-rng-tools component. Maybe a component more
targeted
toward statistic algorithms?
Sampling and statistics do not necessarily belong together.
[This was a discussion in CM.]
But sampling is a direct use of RNG.
* Shuffling algorithm (cf. Commons Math's "o.a.c.m.MathArrays"),
This should go in the ArrayUtils class of commons-lang, with a
java.util.Random parameter.
I don't get that.
The idea is to parameterize the utilities with a
"UniformRandomProvider"
instance.
* Data generation (e.g. random strings, currently defined in
Commons Math's "o.a.c.m.random.RandomUtils"),
I'm not familiar with this, it looks linked to the distribution
stuff.
No, it contains code that was previously in the "RandomDataGenerator"
class; that latter class indeed used to duplicate the sampling
utilities
in the CM "distribution" package.
It also contains functionality that was also developed in Commons Lang.
And generation of hexadecimal string, and picking randomly from a
Collection, etc.
* Syntactic sugar (e.g. strongly-type factory methods, as
suggested by Emmanuel during the RC1 vote),
Having two different factories in two different components for the
same
objects is odd. I prefer only one factory.
So be it; there is one.
I was trying to take care of your use-case.
I think that it is fine to wrap "my" factory into another
offered as syntactic sugar to allow an intelligent IDE
to do its job.
* Bridge/wrappers (as suggested by Emmanuel in RNG-19, on JIRA).
A mere random generator should be in commons-rng.
Wrapping "/dev/random" is out of scope: it is not a mere random
generator.
Scope is: algorithms implemented in Java, in Commons RNG, all
providing the same basic functionality (like save/restore).
And the
java.util.Random bridge also belongs to commons-rng in my opinion,
that's similar to the methods converting from/to java.util.Properties
in
commons-configuration.
As said, the view is not clear; this is not core functionality
(cf. above), it is convenience/utility.
We have to ask questions and provide convincing answers _before_
adding potentially useless code.
What are use-cases for "RandomSource.JDK"?
Gilles
Emmanuel Bourg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
