You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Gilles <gi...@harfang.homelinux.org> on 2016/01/16 16:51:59 UTC
[Math] Revamping the "random" package or ...
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").
Is that possible? [Luc, as the most experienced "git" user,
would you mind managing this, perhaps delicate, operation?]
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.
Regards,
Gilles
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [Math] Revamping the "random" package or ...
Posted by Gilles <gi...@harfang.homelinux.org>.
On Sun, 17 Jan 2016 15:57:51 +0100, Thomas Neidhart wrote:
> On 01/17/2016 02:34 PM, Gilles wrote:
>> On Sun, 17 Jan 2016 10:56:38 +0100, Luc Maisonobe wrote:
>>> Le 16/01/2016 16:51, Gilles a écrit :
>>>> [...]
>>>
>>> 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.
>
> Afaicr we all agreed on going forward with the design as implemented
> for
> the least-squares optimizer by Evan?
Yes.
What I meant is that the current code can run, and that nobody came
up with an alternative that can also run...
Gilles
> Thomas
>
>> 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".
>>
>> Best regards,
>> Gilles
>>
>>> [...]
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [Math] Revamping the "random" package or ...
Posted by Thomas Neidhart <th...@gmail.com>.
On 01/17/2016 02:34 PM, 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.
Afaicr we all agreed on going forward with the design as implemented for
the least-squares optimizer by Evan?
Thomas
> 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".
>
> 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
Re: [Math] Revamping the "random" package or ...
Posted by Luc Maisonobe <lu...@spaceroots.org>.
Le 17/01/2016 18:45, Phil Steitz a écrit :
> On 1/17/16 9:33 AM, Luc Maisonobe wrote:
>> 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?
>
> +1
Done.
Luc
>
> Phil
>>
>> 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
>>
>>
>
>
> ---------------------------------------------------------------------
> 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
Re: [Math] Revamping the "random" package or ...
Posted by Phil Steitz <ph...@gmail.com>.
On 1/17/16 9:33 AM, Luc Maisonobe wrote:
> 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?
+1
Phil
>
> 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
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [Math] Revamping the "random" package or ...
Posted by Luc Maisonobe <lu...@spaceroots.org>.
Le 17/01/2016 20:19, Gilles a écrit :
> Hi Luc.
>
> [Thanks for handling the "revert" chores!]
>
> In my local "git", I've created a branch, called "long-rng",
> initially, as the name indicates, for testing "long"-based
> RNG implementations.
>
> As I've expanded on in other posts, I came to think that
> further changes are needed in order to obtain a cleaner
> design. And since the minimal changes were already
> causing stir, I also figured out that this refactoring
> work should be completed[1] so that the full picture is
> available in order to compare it meaningfully with the
> current code, rather than nit-pick on every incremental
> modification.
>
> So, what I'd thought I could do on my "long-rng" branch is
> 1. create a new "o.a.c.m.rng" package,
> 2. move all (locally) new and modified classes in "o.a.c.m.random"
> over to "o.a.c.m.rng",
> 3. "git pull" in "master" to be current on that branch,
> 4. merge the current master to "long-rng", so that package
> "o.a.c.m.random" is clean, but "o.a.c.m.rng" still contains
> all my local work!
>
> Is that possible?
Probably, yes. I hope the revert I made today will not create
conflicts in your branch. It may create conflicts as your own
cleaning in your local workspace probably touches the same files.
In any cases, these conflicts could be resolved locally.
>
> Of course, simpler would be to just
> 1. create a new clean branch from the current "master", and
> 2. make all the local changes of the last three weeks appear in a
> single commit.
> [Anyways, the "successful development model" blog post discussed
> in another thread recommended this for feature branches.]
>
> Is that OK?
That would be OK too, and as you noted, everything would appear
as a single commit.
best regards,
Luc
> [I would just lose the history of the past 3 weeks (which might
> be a good thing...).]
>
> Is there another better/simpler way?
> Please advise.
>
> Thanks in advance,
> Gilles
>
> [1] There is, unfortunately, not much of either collaborative or
> incremental development happening for CM: New features come in
> big commits of new files and non-compatible changes are stopped
> dead in their tracks.
>
> On Sun, 17 Jan 2016 17:33:27 +0100, Luc Maisonobe wrote:
>> 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
Re: [Math] Revamping the "random" package or ...
Posted by Gilles <gi...@harfang.homelinux.org>.
Hi Luc.
[Thanks for handling the "revert" chores!]
In my local "git", I've created a branch, called "long-rng",
initially, as the name indicates, for testing "long"-based
RNG implementations.
As I've expanded on in other posts, I came to think that
further changes are needed in order to obtain a cleaner
design. And since the minimal changes were already
causing stir, I also figured out that this refactoring
work should be completed[1] so that the full picture is
available in order to compare it meaningfully with the
current code, rather than nit-pick on every incremental
modification.
So, what I'd thought I could do on my "long-rng" branch is
1. create a new "o.a.c.m.rng" package,
2. move all (locally) new and modified classes in "o.a.c.m.random"
over to "o.a.c.m.rng",
3. "git pull" in "master" to be current on that branch,
4. merge the current master to "long-rng", so that package
"o.a.c.m.random" is clean, but "o.a.c.m.rng" still contains
all my local work!
Is that possible?
Of course, simpler would be to just
1. create a new clean branch from the current "master", and
2. make all the local changes of the last three weeks appear in a
single commit.
[Anyways, the "successful development model" blog post discussed
in another thread recommended this for feature branches.]
Is that OK?
[I would just lose the history of the past 3 weeks (which might
be a good thing...).]
Is there another better/simpler way?
Please advise.
Thanks in advance,
Gilles
[1] There is, unfortunately, not much of either collaborative or
incremental development happening for CM: New features come in
big commits of new files and non-compatible changes are stopped
dead in their tracks.
On Sun, 17 Jan 2016 17:33:27 +0100, Luc Maisonobe wrote:
> 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
Re: [Math] Revamping the "random" package or ...
Posted by Luc Maisonobe <lu...@spaceroots.org>.
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
Re: [Math] Revamping the "random" package or ...
Posted by Phil Steitz <ph...@gmail.com>.
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
Re: [Math] Revamping the "random" package or ...
Posted by Gilles <gi...@harfang.homelinux.org>.
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".
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
Re: [Math] Revamping the "random" package or ...
Posted by Luc Maisonobe <lu...@spaceroots.org>.
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.
>
> 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