Re: [ALL] Get things moving with "random utilities"

[Dave Brosius]

+1
---


On 2016-10-19 13:43, Jörg Schaible wrote:

Hi,

Gary Gregory wrote:

To restate my opinion and that of others: It is not a good thing to 
end up
with components Commons Random A, Commons Random B, Commons Random C, 
and
so on. We already have a new Commons Random Something component. 
Related

code should be modules of that component.


let's see it from the practical side. Commons RNG is supposed to stay 
stable

as long as possible. Commons RNG Tools might have a much faster turn to
break APIs. If you put both together, you'll have either to manage the
submodules like individual components with own GAV (and where's the 
benefit
then apart from our unprepared tooling of such an scenario?) or you 
have to
change the package name of Commons RNG quite more often then necessary, 
just
because you restructure something in the RNG tools that is 
incaompatible

(not very good for users of RNG).

Therefore I'm with Gilles here and would simply say: Let's try it with 
two
independent components and time will tell if it was a good choice or 
not.


Cheers,
Jörg


-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org


-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [ALL] Get things moving with "random utilities"

[Jörg Schaible]

Hi,

Gary Gregory wrote:

> To restate my opinion and that of others: It is not a good thing to end up
> with components Commons Random A, Commons Random B, Commons Random C, and
> so on. We already have a new Commons Random Something component. Related
> code should be modules of that component.

let's see it from the practical side. Commons RNG is supposed to stay stable 
as long as possible. Commons RNG Tools might have a much faster turn to 
break APIs. If you put both together, you'll have either to manage the 
submodules like individual components with own GAV (and where's the benefit 
then apart from our unprepared tooling of such an scenario?) or you have to 
change the package name of Commons RNG quite more often then necessary, just 
because you restructure something in the RNG tools that is incaompatible 
(not very good for users of RNG).

Therefore I'm with Gilles here and would simply say: Let's try it with two 
independent components and time will tell if it was a good choice or not.

Cheers,
Jörg


-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [ALL] Get things moving with "random utilities"

[Gilles]

On Tue, 18 Oct 2016 08:46:25 -0700, Gary Gregory wrote:
To restate my opinion and that of others: It is not a good thing to 
end up
with components Commons Random A, Commons Random B, Commons Random C, 
and
so on. We already have a new Commons Random Something component. 
Related

code should be modules of that component.


I'll restate my opinion that it is a bad idea to do it.

But, furthermore, I'll give the reason why it is a bad
idea: We should not confuse the use of a functionality,
with the functionality itself.

What you say above ("related code should be modules") is
akin to saying that all codes that use 
must be shipped in a single library.
[Going even further and citing Jochen, again, the utilities
should be "random source"-neutral (i.e. have their own "RNG"
interface upon which the tools are built), and possibly
provide bridges to/from other libraries API (including a.o.
"UniformRandomProvider" (from "Commons RNG") and the JDK's
"java.util.Random" and "java.util.SplittableRandom".]

Don't you rather think that a good "component" is one that
focuses on its job, without being encumbered by out-of-scope
considerations?

The envisioned "tools" will be on very unstable ground
(their scope is yet _undefined_) for a long time[1], while
"Commons RNG" is (within a scope intended to fit a bona fide
"component") features-complete.  [Well, other features would
be welcome (as I already noted elsewhere), but they are
certainly not required for a "simple API" (which, I suppose,
covers the vast majority of use-cases).]

The two candidate components are completely different beasts.
Grouping them for the sole reason that they both use the word
"random" in their description is a dramatic oversimplification.

[I'm surprised that you do not request that "Commons Crypto"[2]
be merged into "Commons RNG" (or should it be the reverse?)...]

There are many reasons why we all should prefer to keep them
separate.[3]

Perhaps, in the long-term[4], when all the dust has settled,
will I see reasons to merge the two libraries.
In the meantime, none exist (there is no code, is there?),
and I fail to understand how
 * jeopardizing the stability of an existing codebase, and
 * delaying its releases (on the ground that non-existing
   code might be added at some indeterminate future)
are "good thing[s]".

My proposal is _two_[5] components, not "A, B, C and so on"!
One will, some day, provide many modules as client code of any
supported "random sources",[6] and the other can provide, right
now, PRNGs implementations (as a particular type of "random
source").[7]

Sadly, if your above statement uses exaggeration in order to
deform this proposal, it does not give any "positive" argument
against it, for us to think about.
Please, give technical objections to my (positive) arguments.


Regards,
Gilles

[1] The absence of SMEs will increase the number of ways of
getting some of those tools wrong (entailing the need to
break compatibility in order to correct the course).
This happened in CM.
[2] 
http://commons.apache.org/proper/commons-crypto/apidocs/org/apache/commons/crypto/random/CryptoRandom.html

[3] Stated s many times in several other threads.
[4] When people have actually _experimented_ with the ideas
which they think "should work".
[5] It is true however that other "random sources", with features
that _provably_ go beyond the scope of "Commons RNG", should
(IMO) be developed in an additional component, if "separation
of concerns" is something of value to this community.
[6] As explicitly described in the original post (quoted below).
[7] If the name of "Commons RNG" is still the source, not of
uniform randomness, but of community confusion, I'm all for
changing it, so that it more precisely reflect the intended
contents.



Gary

On Tue, Oct 18, 2016 at 7:18 AM, Gilles 


wrote:


Hello Bruno.

On Sat, 15 Oct 2016 20:57:04 + (UTC), Bruno P. Kinoshita wrote:


Hi Gilles,

Definitely interested in helping and learning more about random
(number|string|object|etc) generators.

Are there any specific tasks that others can jump in and help with?



In the yet-to-be-named "Commons " component,
everything is up for grabs, from extracting the relevant bits
from "Math" and "Lang", to proposing an all-encompassing
framework (if people think they can achieve it...).
The scope is open-ended (or should be defined if there is a
willingness to impose some limit).

Once the new component has been set up,




For this, we should start with settling on a name, so that INFRA
can create a repository with that name.

 * Random Utilities
 * Random Utils
 * Random Tools
 * ...

?

I'd be happy in trying to work

on code related to LANG-1196 and LANG-1254.



Thanks!

Regards,
Gilles




Cheers
Bruno



From: Gilles 
To: dev@commons.apache.org
Sent: Sunday, 16 October 2016 5:08 AM
Subject: [ALL] Get things 

Re: [ALL] Get things moving with "random utilities"

[Bruno P. Kinoshita]

Got it. Happy to contribute to an existing component (or a component's module) 
too.

Not sure where would be the best place. Right now the code I'd like to fix is 
in [lang],
used to generate random strings.


It is using Java default util Random object, and would be nice to let users 
change the seed,
but also use different random number generators.

Maybe the code could be a component of [rng], or maybe it could keep in [lang] 
and then just
provide a way for users to supply a random number generator... though I'm not 
really
sure if there is a common interface for these number generators. That way an 
alternative would be
simply generify the RandomStringUtils.


Cheers
B

>
> From: Gary Gregory <garydgreg...@gmail.com>
>To: Commons Developers List <dev@commons.apache.org> 
>Sent: Wednesday, 19 October 2016 4:46 AM
>Subject: Re: [ALL] Get things moving with "random utilities"
> 
>
>To restate my opinion and that of others: It is not a good thing to end up
>with components Commons Random A, Commons Random B, Commons Random C, and
>so on. We already have a new Commons Random Something component. Related
>code should be modules of that component.
>
>Gary
>
>
>On Tue, Oct 18, 2016 at 7:18 AM, Gilles <gil...@harfang.homelinux.org>
>wrote:
>
>> Hello Bruno.
>>
>> On Sat, 15 Oct 2016 20:57:04 + (UTC), Bruno P. Kinoshita wrote:
>>
>>> Hi Gilles,
>>>
>>> Definitely interested in helping and learning more about random
>>> (number|string|object|etc) generators.
>>>
>>> Are there any specific tasks that others can jump in and help with?
>>>
>>
>> In the yet-to-be-named "Commons " component,
>> everything is up for grabs, from extracting the relevant bits
>> from "Math" and "Lang", to proposing an all-encompassing
>> framework (if people think they can achieve it...).
>> The scope is open-ended (or should be defined if there is a
>> willingness to impose some limit).
>>
>> Once the new component has been set up,
>>>
>>
>> For this, we should start with settling on a name, so that INFRA
>> can create a repository with that name.
>>
>>  * Random Utilities
>>  * Random Utils
>>  * Random Tools
>>  * ...
>>
>> ?
>>
>> I'd be happy in trying to work
>>> on code related to LANG-1196 and LANG-1254.
>>>
>>
>> Thanks!
>>
>> Regards,
>> Gilles
>>
>>
>>
>>> Cheers
>>> Bruno
>>>
>>>> 
>>>> From: Gilles <gil...@harfang.homelinux.org>
>>>> 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"))
>>>>
>>>>
>>>> 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").
>>>>
>>>> Exampl

Re: [ALL] Get things moving with "random utilities"

[Gary Gregory]

To restate my opinion and that of others: It is not a good thing to end up
with components Commons Random A, Commons Random B, Commons Random C, and
so on. We already have a new Commons Random Something component. Related
code should be modules of that component.

Gary

On Tue, Oct 18, 2016 at 7:18 AM, Gilles 
wrote:

> Hello Bruno.
>
> On Sat, 15 Oct 2016 20:57:04 + (UTC), Bruno P. Kinoshita wrote:
>
>> Hi Gilles,
>>
>> Definitely interested in helping and learning more about random
>> (number|string|object|etc) generators.
>>
>> Are there any specific tasks that others can jump in and help with?
>>
>
> In the yet-to-be-named "Commons " component,
> everything is up for grabs, from extracting the relevant bits
> from "Math" and "Lang", to proposing an all-encompassing
> framework (if people think they can achieve it...).
> The scope is open-ended (or should be defined if there is a
> willingness to impose some limit).
>
> Once the new component has been set up,
>>
>
> For this, we should start with settling on a name, so that INFRA
> can create a repository with that name.
>
>  * Random Utilities
>  * Random Utils
>  * Random Tools
>  * ...
>
> ?
>
> I'd be happy in trying to work
>> on code related to LANG-1196 and LANG-1254.
>>
>
> Thanks!
>
> Regards,
> Gilles
>
>
>
>> 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"))
>>>
>>>
>>> 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" (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
>
>


-- 
E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
Java Persistence with Hibernate, Second Edition



JUnit in Action, Second Edition

Re: [ALL] Get things moving with "random utilities"

[Gilles]

Hello Bruno.

On Sat, 15 Oct 2016 20:57:04 + (UTC), Bruno P. Kinoshita wrote:

Hi Gilles,

Definitely interested in helping and learning more about random
(number|string|object|etc) generators.

Are there any specific tasks that others can jump in and help with?


In the yet-to-be-named "Commons " component,
everything is up for grabs, from extracting the relevant bits
from "Math" and "Lang", to proposing an all-encompassing
framework (if people think they can achieve it...).
The scope is open-ended (or should be defined if there is a
willingness to impose some limit).


Once the new component has been set up,


For this, we should start with settling on a name, so that INFRA
can create a repository with that name.

 * Random Utilities
 * Random Utils
 * Random Tools
 * ...

?


I'd be happy in trying to work
on code related to LANG-1196 and LANG-1254.


Thanks!

Regards,
Gilles




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"))



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" (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

Re: [ALL] Get things moving with "random utilities" (Was: [lang] Shuffling arrays (was: [RNG] Scope of "Commons RNG"))

[Bruno P. Kinoshita]

Hi Gilles,

Definitely interested in helping and learning more about random 
(number|string|object|etc) generators.

Are there any specific tasks that others can jump in and help with? Once the 
new component has been set up, I'd be happy in trying to work on code related 
to LANG-1196 and 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"))
> 
>
>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" (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
>
>
>
>

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org