commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gary Gregory <garydgreg...@gmail.com>
Subject Re: [ALL] Get things moving with "random utilities"
Date Tue, 18 Oct 2016 15:46:25 GMT
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 <gilles@harfang.homelinux.org>
wrote:

> Hello Bruno.
>
> On Sat, 15 Oct 2016 20:57:04 +0000 (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 <random utilities>" 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 <gilles@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").
>>>
>>> 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<T>" (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-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>


-- 
E-Mail: garydgregory@gmail.com | ggregory@apache.org
Java Persistence with Hibernate, Second Edition
<https://www.amazon.com/gp/product/1617290459/ref=as_li_tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1617290459&linkCode=as2&tag=garygregory-20&linkId=cadb800f39946ec62ea2b1af9fe6a2b8>

<http:////ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=1617290459>
JUnit in Action, Second Edition
<https://www.amazon.com/gp/product/1935182021/ref=as_li_tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1935182021&linkCode=as2&tag=garygregory-20&linkId=31ecd1f6b6d1eaf8886ac902a24de418%22>

<http:////ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=1935182021>
Spring Batch in Action
<https://www.amazon.com/gp/product/1935182951/ref=as_li_tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1935182951&linkCode=%7B%7BlinkCode%7D%7D&tag=garygregory-20&linkId=%7B%7Blink_id%7D%7D%22%3ESpring+Batch+in+Action>
<http:////ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=1935182951>
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message