commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Phil Steitz <phil.ste...@gmail.com>
Subject Re: [Math] Revamping the "random" package or ...
Date Sun, 17 Jan 2016 15:31:52 GMT
On 1/17/16 6:34 AM, Gilles wrote:
> On Sun, 17 Jan 2016 10:56:38 +0100, Luc Maisonobe wrote:
>> Le 16/01/2016 16:51, Gilles a écrit :
>>> Hi.
>>>
>>> Context: nobody gave an opinion on the arguments which I put
>>> forward in these posts:
>>>   http://markmail.org/message/uiljlf63uucnfyy2
>>>   http://markmail.org/message/ifwuijbgjytne6w2
>>>
>>> As a consequence, the lack of any development policy, rather
>>> than being the touted advantage of the "free world" of Apache,
>>> is, objectively, a quite efficient way to push in the direction
>>> of the stronger voice, not necessarily backed with the stronger
>>> arguments (especially when those are not "technical" but, in
>>> reality, "political"!).
>>> This has been the subject of another post, that also was not
>>> followed by a constructive debate in order to change this
>>> community's ways, so that it would not discourage proposals
>>> for code evolutions towards a modern use of the Java language.
>>>
>>> Thus, in this context, I obviously can't know whether "silence
>>> is consent" or if people will continue raising objections to my
>>> experimenting with the contents of the "random" package, even
>>> after not raising concern and/or not engaging in the practical
>>> discussions about the proposals.
>>>
>>> Also, it is disrespectful to let people think that they could
>>> work on some part of the library, and then voice an opinion
>>> akin to the hidden policy that there exists, in CM, codes
>>> that are deemed too sensitive to be ever touched again.
>>>
>>> My first idea was to make incremental changes in "random".
>>> The first few, and little, steps unexpectedly implied a huge
>>> amount of work, mainly due to the disproportionate
>>> justifications that were being required.
>>>
>>> It is a fact that even tiny, even no-op, changes meet
>>> infinitely more opposition than adding even very large chunks
>>> of new code.
>>>
>>> Hence, I propose that all my recent changes to the "random"
>>> package be reverted so that it will match the contents of the
>>> 3.6 release (modulo the changes which were explicitly agreed
>>> on like those in "RandomGeneratorAbstractTest").
>>
>> I did answer to at least part of your proposals, and suggested
>> this experimentation is done on a branch.
>> At the same time, you also proposed to adopt another branching
>> policy, and this was seen positively by anyone.
>>
>> So I would suggest that rather than adding a parallel rng package,
>> which reminds me of the difficulties we get with the two optim and
>> optimization packages, you continue doing your changes directly
>> in the random package as you started to do, but in a feature branch.
>
> Sorry, but I don't agree.
> I've explained that I want to propose as a *replacement* to "random".
> Almost every file will be changed, and a basic requirement is to have
> the RNGs, and only the RNGs, in their own package/module.
>
> So for example, "RandomDataGenerator" and "ValueServer", as "users"
> of the RNGs, should not be in the "rng" package (but but stay in
> "random" whatever else changed or delete there).
>
> This situation here cannot be more different than for the "optim"
> package!
> First, the old "optimization" _has_ been deleted in "master"; we
> had to keep it in the 3.x line.
> The code in "optim" has been been criticized but until now nobody
> came up with a better proposal, so the only working code must
> obviously stay.
>
> For "rng", I'll propose a working remplacement, and we'll be able
> to immediately decide whether to keep "random" as is or adapt it
> in order to remove the redundancy with the new "rng" and/or write
> some adaptation layers from "random" to "rng".

+1 to separate the PRNG abstract class(es)? and impls into a
separate package called "rng."  I would personally favor making that
a subpackage of random.

Phil
>
> Best regards,
> Gilles
>
>>>
>>> Is that possible?  [Luc, as the most experienced "git" user,
>>> would you mind managing this, perhaps delicate, operation?]
>>
>> Reverting is not difficult. Remember the trick discussed on
>> this list to port commits between math3 and math4? It was
>> basically doing a "git diff -p some-commit~1 some-commit",
>> then patching the commit with a sed and applying it later on.
>>
>> Here is it even simpler because we don't have to patch the commit.
>> The trick is to do the git diff the other way round, i.e.
>> "git diff -p some-commit some-commit~1".
>>
>> Also rather than reverting them and restarting again, in
>> order not to lose your work I'll cut a new feature branch
>> first, then revert on master only. You will be able to
>> continue your work on the feature branch.
>>
>> On a related subject, I also read on another list that infra
>> now allows deleting branches again. The concerns I had with
>> short-lived hotfix branches are therefore not realistic
>> anymore, we can do as many brnahces and as short-lived as we want.
>>
>>>
>>> I would then pursue my refactoring in a new package named
>>>   org.apache.commons.math4.rng
>>> where all the modifications, that led to the latest outburst of
>>> conservatism, will take place.
>>> It will also allow me to further experiment and see where it
>>> leads, without having to argue endlessly on every compatibility
>>> breaking.
>>>
>>> In effect, it's a fork of "random" (but within CM).
>>> Of course, this will happen in a "feature branch" which I'll
>>> create upstream when the renaming has been performed.
>>>
>>> Then people can see both sets of codes "side-by-side", analyze
>>> them, experiment with usage, and run benchmarks of the alternative
>>> versions of the RNG classes.
>>>
>>> Ultimately, if the rift between conservatists and modernists
>>> remains, both the "random" and the "rng" packages can coexist
>>> in the 4.0 release of the library.
>>
>> I would really prefer not to live again the
>> optim/optimization/least squares nightmare.
>>
>> best regards,
>> Luc
>>
>>>
>>>
>>> Regards,
>>> Gilles
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>


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


Mime
View raw message