LANG-1254.
Cheers
Bruno
>
> From: Gilles
>To: dev@commons.apache.org
>Sent: Sunday, 16 October 2016 5:08 AM
>Subject: [ALL] Get things moving with "random utilities" (Was: [lang]
>Shuffling arrays (was: [RNG] Scope of "Commons RNG&qu
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 rel
On 27 September 2016 at 12:22, Gilles wrote:
> Hi.
>
> On Tue, 27 Sep 2016 12:53:33 +0200, Emmanuel Bourg wrote:
>>
>> Le 27/09/2016 à 01:14, Gilles a écrit :
>>
> * Shuffling algorithm (cf. Commons Math's "o.a.c.m.MathArrays"),
This should go in the ArrayUtils class of commons-
On Tue, 27 Sep 2016 20:07:19 -0500, Brent Worden wrote:
On Mon, Sep 26, 2016 at 11:36 PM, Gilles
wrote:
On Mon, 26 Sep 2016 21:23:24 -0500, Brent Worden wrote:
With that said, I started thinking a bridge to go between the two
engines,
UniformRandomProvider and java.util.Random, might be b
On Mon, Sep 26, 2016 at 11:36 PM, Gilles
wrote:
> On Mon, 26 Sep 2016 21:23:24 -0500, Brent Worden wrote:
>
>>
>> With that said, I started thinking a bridge to go between the two engines,
>> UniformRandomProvider and java.util.Random, might be beneficial. For
>> third
>> parties that have imple
Hi.
On Tue, 27 Sep 2016 12:53:33 +0200, Emmanuel Bourg wrote:
Le 27/09/2016 à 01:14, Gilles a écrit :
* 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
Le 27/09/2016 à 01:14, Gilles a écrit :
>>> * 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 "UniformRandomP
On Mon, 26 Sep 2016 21:23:24 -0500, Brent Worden wrote:
On Mon, Sep 26, 2016 at 6:21 PM, Gilles
wrote:
On Mon, 26 Sep 2016 16:10:12 -0500, Brent Worden wrote:
I would keep the JDK source. My reasoning being:
1. Users that want to use java.util.Random would not be able to use
some
or
all
On Mon, 26 Sep 2016 21:22:35 -0500, Brent Worden wrote:
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 comp
On Mon, Sep 26, 2016 at 6:21 PM, Gilles
wrote:
> On Mon, 26 Sep 2016 16:10:12 -0500, Brent Worden wrote:
>
>> I would keep the JDK source. My reasoning being:
>>
>> 1. Users that want to use java.util.Random would not be able to use some
>> or
>> all of the RNG Utils code as the later will proba
> 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
>
On Mon, 26 Sep 2016 16:10:12 -0500, Brent Worden wrote:
I would keep the JDK source. My reasoning being:
1. Users that want to use java.util.Random would not be able to use
some or
all of the RNG Utils code as the later will probably relay on
RandomSource
instances.
I don't understand the
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 cle
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 e
I would keep the JDK source. My reasoning being:
1. Users that want to use java.util.Random would not be able to use some or
all of the RNG Utils code as the later will probably relay on RandomSource
instances.
2. With LCGs the current Random implementation provided by Oracle could
possibly be e
Hi.
Reviving this thread following a new feature request:
https://issues.apache.org/jira/browse/RNG-19
IMHO, the request departs from the initial goal (and, hence
the design "requirements" on which the current code is based).
As I suggested previously on this list, I'm going to request
a new
Le 21/09/2016 à 14:46, Gilles a écrit :
> If we want "Commons RNG" to be a repository of all
> generators that exist out there, irrespective of their
> known weaknesses, it's fine; but we should be careful to
> not let casual users just pick one of the implementations
> on the premise that the lib
Hello.
This is a post to ask about what we want "Commons RNG"
to be (as a service to the users).
In the Wikipedia pages referred to in the following
reports
https://issues.apache.org/jira/browse/RNG-16
https://issues.apache.org/jira/browse/RNG-17
the take-away message (IIUC) is that LCG and
18 matches
Mail list logo
