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
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
12 matches
Mail list logo
