commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Luc Maisonobe <...@spaceroots.org>
Subject Re: [Math] Revamping the "random" package or ...
Date Sun, 17 Jan 2016 16:33:27 GMT
Le 17/01/2016 16:31, Phil Steitz a écrit :
> 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.

OK. Then we can simply delete the current random-revamp branch.
Anyway, cutting the branch before the revert was an error from
a git point of view. It would have created lots of conflicts
on the merge operation. So if a random-revamp branch is
really used, it should rather be cut again from the current
master.

Do you agree that I delete this ill-formed random-revamp branch,
which currently has no commits at all?

best regards
Luc

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


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


Mime
View raw message