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