On Thu, 29 Sep 2016 12:19:44 +0200, Emmanuel Bourg wrote:
Le 29/09/2016 à 12:12, er...@apache.org a écrit :
+ <p>
+ Commons RNG is intended to be a repository of pure Java
implementations of
+ random number generators that produce deterministic
sequences.
+ The current design has made no provision for features
generally needed for
+ cryptography applications (e.g. strong unpredictability).
+ </p>
I disagree to limiting the scope of Commons RNG to pure Java
implementations. If some day we want to interface with a native RNG
library it should be possible.
I don't think it is a good idea.
Commons RNG should be a lowest-level, portable, component.
Java port of PRNG algorithms is a fine scope.
Of course, more features can be imagined, but where is it written
that a component should be ever-expanding?
PRNG are comparatively simple to port (code is either short or
very short); hence it is borderline insane to engage with native
code rather than convert the actual algorithm into Java.
I also disagree to the limitation to deterministic generators. True
random generators should be allowed.
Could you please provide some links to documents that would
justify your stance?
Everything I read since I started working on this code indicates
that the mix you propose is a very bad idea.
The concepts look the same only superficially.
To take care of every case is going to be very difficult given
there are no experts around here. The resulting code will be
much more complex and doomed to be incomplete.
As long as practical ideas are still lacking in support
of your proposal, I refuse to jeopardize the viability of a
yet-unborn component by being over-optimistic in our capacity
to come up with a design able to encompass all the features
of cryptographic-strength, or just "true", generators.[1]
Even if that would be possible (which I doubt it is with the
current design), the simple API will be lost (and with it the
whole point of this work which I started last year[2]).
Several RNG could yet be added to "Commons RNG" so that work
within the intended scope is not lacking.
Nothing prevents you from creating a new component dedicated
to these other fields.
Then, when we _see_ that there are convergences, we can
continue this conversation.
Gilles
[1] For "true" generators, software (as we deal with, here)
is a marginal part. Interfacing with sources of true
randomness is a project in itself.
Moreover I suspect that the user bases of true (thus:
non-reproducible) randomness and PRNG algorithms do not
overlap. Hence why should the two be defined in the same
tool?
[2] With a goal known to all: Salvage a refactored package,
from the now unmaintained Commons Math component, whose
contents was pure Java RNG implementations.
Emmanuel Bourg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
