On Fri, 30 Dec 2016 17:30:17 +0000 (UTC), Bernd Eckenfels wrote:
Sorry I meant *uniform* distribution
Gruss
Bernd
On Fri, Dec 30, 2016 at 5:58 PM +0100, "Bernd Eckenfels"
<e...@zusammenkunft.net> wrote:
Hello,
I am somewhat unclear, why would you require a random distribution
(Interface).
Who said?
Is there no better more generic Interface in RNG-API?
Have you had a look at
http://commons.apache.org/proper/commons-rng/commons-rng-client-api/index.html
?
Having said that I still think j.u.Random is fine
Have you read
http://commons.apache.org/proper/commons-rng/userguide/why_not_java_random.html
?
Why use a poor algorithm when using a better one is as easy?
- but if not maybe a
byte or int Provider would be better than a specific interface for
the
random source.
I don't follow.
How do you define this "Provider" if not with an interface?
Gilles
Gruss
Bernd
--
http://bernd.eckenfels.net
On Fri, Dec 30, 2016 at 5:04 PM +0100, "Jörg Schaible"
<joerg.schai...@gmx.de> wrote:
Gilles wrote:
Hi.
On Fri, 30 Dec 2016 09:40:20 -0500, Rob Tompkins wrote:
Hello all,
Personally, I would like to resolve the TEXT-36 and TEXT-42 Jira
tickets before proceeding with the release, but I wanted to check
to
see if anyone else has any opinions on what work needs to be
completed
before the release.
Regarding TEXT-36: 'Dependency on “Commons RNG” ‘, I’m relatively
indifferent here, I just want some other’s to weigh in as to their
thoughts before deciding to leave in the dependency
I don't follow.
Currently, there is no dependency towards RNG.
Personally, I'm in favour of an API that "advertizes" and recommends
usage of its RNG sibling component. [As [TEXT] is, admittedly, a
high-level component (and it already depends on [LANG]).]
However a consensual proposal would be to define a custom interface
(see JIRA discussion), and define the API around it.
[TEXT] should be made "multimodule"; it could then provide bridges
(cf. JIRA comment) in separate modules:
* commons-text-core (algos)
* commons-text-commons-rng-bridge (from
"o.a.c.rng.UniformRandomProvider")
* commons-text-jdk-bridge (from "java.util.Random")
The dependency towards Commons RNG thus becomes optional.
But application developers have to explicitly choose an
implementation (which is good).
You can achieve something similar by declaring commons-rng as
optional. If
you introduce an API for the random functionality and one
implementation is
based on commons-rng, any user will have to declare this dependency
on his
own if he like to use this implementation.
We have a similar setup in vfs where you have to declare jsch as
dependency
on your own if you want SSH support for the protocol in use.
and making more
progress on the best pattern after the 1.0 release.
API decisions must be made before a major release.
The best pattern is the above (IMHO, and as per Jochen's note):
higher flexibility and higher correctness.
Cheers,
Jörg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
