You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Rob Tompkins <ch...@gmail.com> on 2016/09/17 13:32:20 UTC
[MATH] Thoughts on some short term goals?
Hello,
Given that the long term goals of commons-math are fairly uncertain, I would like to attempt working with some short term goals. The hope here is to think about questions along the lines of: "what can be done today/this week/this month,” with the goal aiming at chipping away at what I’ll call, for lack of a better term, technical debt. I have a couple of thoughts and am curious to see what folks generally think here. Here are some ideas that immediately come to mind:
Items achievable in a few hours:
Move to the develop branch to the master branch.
Get travis-ci/coveralls working for pull requests.
Items achievable in a few days:
Deprecation of the packages that duplicate functionality with commons-rng.
Obvious bug fixes.
Items achievable in a month(s) or so.
A release 3.6.2 with the deprecation of the overlap with commons-rng.
Some solidifying of the more base level functionality such that we might be able to rely upon commons-math as the core of the mathematical functionality for commons generally (if we do indeed intend to have modularized mathematical commons functionality).
All that said, these are just thoughts, and I’m completely open ended on direction here but want to avoid letting the project sit latent for too long. I was just thinking that with so much uncertainty for the project, it might be better to just be intentionally short sighted with the hopes of gaining some momentum and let natural evolution begin to take place. What do you guys think?
Cheers,
-Rob
Re: [MATH] Thoughts on some short term goals?
Posted by Jörg Schaible <jo...@gmx.de>.
Hi Rob,
Rob Tompkins wrote:
>
>
>> On Sep 18, 2016, at 7:22 AM, Gilles <gi...@harfang.homelinux.org> wrote:
>>
>> Hello.
>>
>> On Sat, 17 Sep 2016 16:07:41 +0200, J�rg Schaible wrote:
>>> Hi Rob,
>>>
>>> Rob Tompkins wrote:
>>>
>>>> Hello,
>>>>
>>>> Given that the long term goals of commons-math are fairly uncertain, I
>>>> would like to attempt working with some short term goals. The hope here
>>>> is to think about questions along the lines of: "what can be done
>>>> today/this week/this month,\u201d with the goal aiming at chipping away at
>>>> what I\u2019ll call, for lack of a better term, technical debt. I have a
>>>> couple of thoughts and am curious to see what folks generally think
>>>> here. Here are some ideas that immediately come to mind:
>>>>
>>>> Items achievable in a few hours:
>>>> Move to the develop branch to the master branch.
>>>> Get travis-ci/coveralls working for pull requests.
>
> Given the lack of comments here, that feels like a "go for it.\u201d But, I am
> curious what the code in \u201cmaster\u201d represents? I ask because it seems that
> it\u2019s drifted considerably from the release of 3.6.1.
>
> If I do go down this road, I probably would keep the current master branch
> around for a while labeled as \u201cmaster-old-<dateOfChange>\u201d (or something
> along those lines).
Current master is a dead end. We may actually move master to a 4.x branch
and move 3.x back to master, since we we will have for the time being no
further development in Math4 that justifies a break of API.
>>>> Items achievable in a few days:
>>>> Deprecation of the packages that duplicate functionality with
>>>> commons-rng.
>>>
>>> +1 ... normally. However, IIRC correctly, Gilles once said that all the
>>> RNG stuff was never part of a release.
>>
>> The package
>> org.apache.commons.math4.rng
>> was created in the development branch (released CM code was from
>> the "MATH_3_X" branch) intended for work towards v4.0 (which
>> started in early 2015, by removing long deprecated codes).
>>
>> It was a complete rewrite (with fixes, extensions, additions, and
>> removals) of code from
>> org.apache.commons.math4.random
>> which has existed for a long time, and was named
>> org.apache.commons.math3.random
>> in branch MATH_3_X
>>
>> IIUC, Rob means to deprecate, in branch "MATH_3_X", codes in
>> o.a.c.math3.random
>> that could be replaced by equivalent functionality defined
>> in Commons RNG.
>>
>> A minor release of CM3 would warn users about the changes to
>> come.
>> If they use the functionality from
>> o.a.c.math3.random
>> in their own codes, they will already be able to upgrade
>> (to Commons RNG).
>> But if they use CM3 generators as arguments in calls to CM3,
>> then no replacements will be available, as only (unreleased)
>> CM4 can be (and has been) upgraded to depend on Commons RNG.
>
> This would precisely be the idea. If we are intent on modularization, then
> we should slim down the commons-math library such that it contains no
> duplications from other commons components.
+1, that's IMHO the best "upgrade" path for existing Math users.
> Lastly given those ideas, does anyone else have any ideas for what we can
> do right now on commons-math?
Well, there are a bunch of Gilles' ideas left ;-)
Cheers,
J�rg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [MATH] Thoughts on some short term goals?
Posted by Gilles <gi...@harfang.homelinux.org>.
On Mon, 19 Sep 2016 07:03:44 -0400, Rob Tompkins wrote:
>> On Sep 18, 2016, at 7:22 AM, Gilles <gi...@harfang.homelinux.org>
>> wrote:
>>
>> Hello.
>>
>> On Sat, 17 Sep 2016 16:07:41 +0200, J�rg Schaible wrote:
>>> Hi Rob,
>>>
>>> Rob Tompkins wrote:
>>>
>>>> Hello,
>>>>
>>>> Given that the long term goals of commons-math are fairly
>>>> uncertain, I
>>>> would like to attempt working with some short term goals. The hope
>>>> here is
>>>> to think about questions along the lines of: "what can be done
>>>> today/this
>>>> week/this month,\u201d with the goal aiming at chipping away at what
>>>> I\u2019ll call,
>>>> for lack of a better term, technical debt. I have a couple of
>>>> thoughts and
>>>> am curious to see what folks generally think here. Here are some
>>>> ideas
>>>> that immediately come to mind:
>>>>
>>>> Items achievable in a few hours:
>>>> Move to the develop branch to the master branch.
>>>> Get travis-ci/coveralls working for pull requests.
>
> Given the lack of comments here, that feels like a "go for it.\u201d But,
> I am curious what the code in \u201cmaster\u201d represents? I ask because it
> seems that it\u2019s drifted considerably from the release of 3.6.1.
>
> If I do go down this road, I probably would keep the current master
> branch around for a while labeled as \u201cmaster-old-<dateOfChange>\u201d (or
> something along those lines).
>
>>>>
>>>> Items achievable in a few days:
>>>> Deprecation of the packages that duplicate functionality with
>>>> commons-rng.
>>>
>>> +1 ... normally. However, IIRC correctly, Gilles once said that all
>>> the RNG
>>> stuff was never part of a release.
>>
>> The package
>> org.apache.commons.math4.rng
>> was created in the development branch (released CM code was from
>> the "MATH_3_X" branch) intended for work towards v4.0 (which
>> started in early 2015, by removing long deprecated codes).
>>
>> It was a complete rewrite (with fixes, extensions, additions, and
>> removals) of code from
>> org.apache.commons.math4.random
>> which has existed for a long time, and was named
>> org.apache.commons.math3.random
>> in branch MATH_3_X
>>
>> IIUC, Rob means to deprecate, in branch "MATH_3_X", codes in
>> o.a.c.math3.random
>> that could be replaced by equivalent functionality defined
>> in Commons RNG.
>>
>> A minor release of CM3 would warn users about the changes to
>> come.
>> If they use the functionality from
>> o.a.c.math3.random
>> in their own codes, they will already be able to upgrade
>> (to Commons RNG).
>> But if they use CM3 generators as arguments in calls to CM3,
>> then no replacements will be available, as only (unreleased)
>> CM4 can be (and has been) upgraded to depend on Commons RNG.
>
> This would precisely be the idea. If we are intent on modularization,
> then we should slim down the commons-math library such that it
> contains no duplications from other commons components.
I'm not sure that everyone say the same thing.
Slimming down of CM4 has been done.
Functionality can be deprecated in CM3, but replacing it in the same
way as in CM4 cannot be performed completely (some of it is breaking)
and it is a huge waste of time (better spent IMO at resolving the
backlog in CM4, and striding towards modularization, of course).
> Lastly given those ideas, does anyone else have any ideas for what we
> can do right now on commons-math?
"Commons RNG-Utils" (cf. other post).
Regards,
Gilles
> Cheers.
> -Rob
>
>>
>> Regards,
>> Gilles
>>
>> P.S. Your +1 vote was a pleasant surprise; thanks!
>>
>>> In that case this code can be simply
>>> dropped.
>>>
>>>> Obvious bug fixes.
>>>>
>>>> Items achievable in a month(s) or so.
>>>> A release 3.6.2 with the deprecation of the overlap with
>>>> commons-rng.
>>>> Some solidifying of the more base level functionality such that we
>>>> might
>>>> be able to rely upon commons-math as the core of the mathematical
>>>> functionality for commons generally (if we do indeed intend to
>>>> have
>>>> modularized mathematical commons functionality).
>>>>
>>>> All that said, these are just thoughts, and I\u2019m completely open
>>>> ended on
>>>> direction here but want to avoid letting the project sit latent
>>>> for too
>>>> long. I was just thinking that with so much uncertainty for the
>>>> project,
>>>> it might be better to just be intentionally short sighted with the
>>>> hopes
>>>> of gaining some momentum and let natural evolution begin to take
>>>> place.
>>>> What do you guys think?
>>>
>>> Fine. Thanks for taking responsibility.
>>>
>>> Cheers,
>>> J�rg
>>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [MATH] Thoughts on some short term goals?
Posted by Rob Tompkins <ch...@gmail.com>.
> On Sep 18, 2016, at 7:22 AM, Gilles <gi...@harfang.homelinux.org> wrote:
>
> Hello.
>
> On Sat, 17 Sep 2016 16:07:41 +0200, Jörg Schaible wrote:
>> Hi Rob,
>>
>> Rob Tompkins wrote:
>>
>>> Hello,
>>>
>>> Given that the long term goals of commons-math are fairly uncertain, I
>>> would like to attempt working with some short term goals. The hope here is
>>> to think about questions along the lines of: "what can be done today/this
>>> week/this month,” with the goal aiming at chipping away at what I’ll call,
>>> for lack of a better term, technical debt. I have a couple of thoughts and
>>> am curious to see what folks generally think here. Here are some ideas
>>> that immediately come to mind:
>>>
>>> Items achievable in a few hours:
>>> Move to the develop branch to the master branch.
>>> Get travis-ci/coveralls working for pull requests.
Given the lack of comments here, that feels like a "go for it.” But, I am curious what the code in “master” represents? I ask because it seems that it’s drifted considerably from the release of 3.6.1.
If I do go down this road, I probably would keep the current master branch around for a while labeled as “master-old-<dateOfChange>” (or something along those lines).
>>>
>>> Items achievable in a few days:
>>> Deprecation of the packages that duplicate functionality with commons-rng.
>>
>> +1 ... normally. However, IIRC correctly, Gilles once said that all the RNG
>> stuff was never part of a release.
>
> The package
> org.apache.commons.math4.rng
> was created in the development branch (released CM code was from
> the "MATH_3_X" branch) intended for work towards v4.0 (which
> started in early 2015, by removing long deprecated codes).
>
> It was a complete rewrite (with fixes, extensions, additions, and
> removals) of code from
> org.apache.commons.math4.random
> which has existed for a long time, and was named
> org.apache.commons.math3.random
> in branch MATH_3_X
>
> IIUC, Rob means to deprecate, in branch "MATH_3_X", codes in
> o.a.c.math3.random
> that could be replaced by equivalent functionality defined
> in Commons RNG.
>
> A minor release of CM3 would warn users about the changes to
> come.
> If they use the functionality from
> o.a.c.math3.random
> in their own codes, they will already be able to upgrade
> (to Commons RNG).
> But if they use CM3 generators as arguments in calls to CM3,
> then no replacements will be available, as only (unreleased)
> CM4 can be (and has been) upgraded to depend on Commons RNG.
This would precisely be the idea. If we are intent on modularization, then we should slim down the commons-math library such that it contains no duplications from other commons components.
Lastly given those ideas, does anyone else have any ideas for what we can do right now on commons-math?
Cheers.
-Rob
>
> Regards,
> Gilles
>
> P.S. Your +1 vote was a pleasant surprise; thanks!
>
>> In that case this code can be simply
>> dropped.
>>
>>> Obvious bug fixes.
>>>
>>> Items achievable in a month(s) or so.
>>> A release 3.6.2 with the deprecation of the overlap with commons-rng.
>>> Some solidifying of the more base level functionality such that we might
>>> be able to rely upon commons-math as the core of the mathematical
>>> functionality for commons generally (if we do indeed intend to have
>>> modularized mathematical commons functionality).
>>>
>>> All that said, these are just thoughts, and I’m completely open ended on
>>> direction here but want to avoid letting the project sit latent for too
>>> long. I was just thinking that with so much uncertainty for the project,
>>> it might be better to just be intentionally short sighted with the hopes
>>> of gaining some momentum and let natural evolution begin to take place.
>>> What do you guys think?
>>
>> Fine. Thanks for taking responsibility.
>>
>> Cheers,
>> Jörg
>>
>
>
> ---------------------------------------------------------------------
> 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] Thoughts on some short term goals?
Posted by Gilles <gi...@harfang.homelinux.org>.
Hello.
On Sat, 17 Sep 2016 16:07:41 +0200, J�rg Schaible wrote:
> Hi Rob,
>
> Rob Tompkins wrote:
>
>> Hello,
>>
>> Given that the long term goals of commons-math are fairly uncertain,
>> I
>> would like to attempt working with some short term goals. The hope
>> here is
>> to think about questions along the lines of: "what can be done
>> today/this
>> week/this month,\u201d with the goal aiming at chipping away at what I\u2019ll
>> call,
>> for lack of a better term, technical debt. I have a couple of
>> thoughts and
>> am curious to see what folks generally think here. Here are some
>> ideas
>> that immediately come to mind:
>>
>> Items achievable in a few hours:
>> Move to the develop branch to the master branch.
>> Get travis-ci/coveralls working for pull requests.
>>
>> Items achievable in a few days:
>> Deprecation of the packages that duplicate functionality with
>> commons-rng.
>
> +1 ... normally. However, IIRC correctly, Gilles once said that all
> the RNG
> stuff was never part of a release.
The package
org.apache.commons.math4.rng
was created in the development branch (released CM code was from
the "MATH_3_X" branch) intended for work towards v4.0 (which
started in early 2015, by removing long deprecated codes).
It was a complete rewrite (with fixes, extensions, additions, and
removals) of code from
org.apache.commons.math4.random
which has existed for a long time, and was named
org.apache.commons.math3.random
in branch MATH_3_X
IIUC, Rob means to deprecate, in branch "MATH_3_X", codes in
o.a.c.math3.random
that could be replaced by equivalent functionality defined
in Commons RNG.
A minor release of CM3 would warn users about the changes to
come.
If they use the functionality from
o.a.c.math3.random
in their own codes, they will already be able to upgrade
(to Commons RNG).
But if they use CM3 generators as arguments in calls to CM3,
then no replacements will be available, as only (unreleased)
CM4 can be (and has been) upgraded to depend on Commons RNG.
Regards,
Gilles
P.S. Your +1 vote was a pleasant surprise; thanks!
> In that case this code can be simply
> dropped.
>
>> Obvious bug fixes.
>>
>> Items achievable in a month(s) or so.
>> A release 3.6.2 with the deprecation of the overlap with
>> commons-rng.
>> Some solidifying of the more base level functionality such that we
>> might
>> be able to rely upon commons-math as the core of the mathematical
>> functionality for commons generally (if we do indeed intend to have
>> modularized mathematical commons functionality).
>>
>> All that said, these are just thoughts, and I\u2019m completely open
>> ended on
>> direction here but want to avoid letting the project sit latent for
>> too
>> long. I was just thinking that with so much uncertainty for the
>> project,
>> it might be better to just be intentionally short sighted with the
>> hopes
>> of gaining some momentum and let natural evolution begin to take
>> place.
>> What do you guys think?
>
> Fine. Thanks for taking responsibility.
>
> Cheers,
> J�rg
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [MATH] Thoughts on some short term goals?
Posted by Emmanuel Bourg <eb...@apache.org>.
Le 17/09/2016 � 16:07, J�rg Schaible a �crit :
> +1 ... normally. However, IIRC correctly, Gilles once said that all the RNG
> stuff was never part of a release. In that case this code can be simply
> dropped.
Actually some of the RNG stuff has been in Commons Math for years, the
RandomGenerator interface was in Commons Math 1.1 released in 2005,
MersenneTwister arrived in 2.0 (2009), the Well generators in 2.2 (2011)
and ISAAC in 3.0 (2012).
Emmanuel Bourg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [MATH] Thoughts on some short term goals?
Posted by Jörg Schaible <jo...@gmx.de>.
Hi Rob,
Rob Tompkins wrote:
> Hello,
>
> Given that the long term goals of commons-math are fairly uncertain, I
> would like to attempt working with some short term goals. The hope here is
> to think about questions along the lines of: "what can be done today/this
> week/this month,\u201d with the goal aiming at chipping away at what I\u2019ll call,
> for lack of a better term, technical debt. I have a couple of thoughts and
> am curious to see what folks generally think here. Here are some ideas
> that immediately come to mind:
>
> Items achievable in a few hours:
> Move to the develop branch to the master branch.
> Get travis-ci/coveralls working for pull requests.
>
> Items achievable in a few days:
> Deprecation of the packages that duplicate functionality with commons-rng.
+1 ... normally. However, IIRC correctly, Gilles once said that all the RNG
stuff was never part of a release. In that case this code can be simply
dropped.
> Obvious bug fixes.
>
> Items achievable in a month(s) or so.
> A release 3.6.2 with the deprecation of the overlap with commons-rng.
> Some solidifying of the more base level functionality such that we might
> be able to rely upon commons-math as the core of the mathematical
> functionality for commons generally (if we do indeed intend to have
> modularized mathematical commons functionality).
>
> All that said, these are just thoughts, and I\u2019m completely open ended on
> direction here but want to avoid letting the project sit latent for too
> long. I was just thinking that with so much uncertainty for the project,
> it might be better to just be intentionally short sighted with the hopes
> of gaining some momentum and let natural evolution begin to take place.
> What do you guys think?
Fine. Thanks for taking responsibility.
Cheers,
J�rg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org