Hi.
On Fri, 7 Oct 2016 16:00:05 +0100, sebb wrote:
[...]
But overall it would be much better to put all this in a new
component
and deprecate all of CL's "Random"-parameterized methods.
It was noted (not only by me) that CL grew too big (and out of its
original
scope). "RandomUtils" is relatively small (in Lang 3.4): now is a
good
opportunity to deprecate these few methods and those intended for
3.5
and redirect users to a dedicated component.
+1
[...]
Within the context of a forthcoming release of "Commons RNG" and
identified shortcomings of the random-related utilities implemented
in "Commons Lang", e.g.:
https://issues.apache.org/jira/browse/LANG-1196
https://issues.apache.org/jira/browse/LANG-1254
I'm proposing to ask INFRA to create a new git repository, to become
the "Commons" home of random utilities, i.e. anything that _uses_ an
"external" source of randomness (as opposed to _implementations_
of (P)RNG algorithms, which is the scope of "Commons RNG").
Examples of utilities:
* non-uniform deviates (to be extracted from "Commons Math")
* extended tools, such as "numbers within a range" (to be
extracted from "Commons Lang") and "quasi-random" generators
(to be extracted from "Commons Math"),
* string utilities (to be extracted from "Commons Math" and
"Commons Lang"),
* shuffling of primitive arrays and "List<T>" (to be extracted
from "Commons Math"),
* bridges between alternative APIs:
- java.util.Random
- java.util.SplittableRandom
- UniformRandomProvider from "Commons RNG" (to be extracted
from "Commons Math")
- other Java libraries
* wrappers around "external" sources of randomness, e.g. system
devices (UNIX) and native libraries, and interface extensions
needed to support them (streams, IO handling, etc.).
Given the variety of the above (non-exhaustive) list, it is
foreseen that the component will be "multi-modules"[1] in order
to let users depend only on what they need for their use-case.
[For example, an engineering application could need non-uniform
deviates (e.g. Gaussian-distributed sequences), but should not
be required to depend on the (orthogonal) development of string
generators or cryptographic features.]
Regards,
Gilles
[1] Help is most welcome to set this up.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
