commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gilles <gil...@harfang.homelinux.org>
Subject Re: [ALL] Get things moving with "random utilities"
Date Wed, 19 Oct 2016 16:02:52 GMT
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 <some Java interface>
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 soooo 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 
> <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


Mime
View raw message