You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Luc Maisonobe <Lu...@free.fr> on 2011/11/23 10:19:01 UTC
[math] release plan for 3.0 ?
Hello,
I have had several questions about release plans for 3.0.
I feel guilty for not having pushed this version out yet. It is not in
release shape now and many thing are still ongoing. Typically, a new
thread as been started a few hours ago about an important change in the
linear algebra API (a needed change, so something important to discuss now).
As far as I am concerned, here are the points I want to address myself
(but if other people want to help, chime in!). I would like to see what
other developers have in mind so wa can set up a release plan, and
really work toward a release which is past due.
My personal tasks are:
- finish the adapters wrapping unbounded optimizers into simple bounds
optimizers as set up by Gilles, using the two function adapters
already available
- stabilize Adams based ODE integrators using the
MathUtils.linearCombination feature to ensure better accuracy and
error estimates in the Nordsieck vectors
- perhaps add back the BDF integrator for stiff problems, using the
Nordsieck vectors once it has been stabilized for Adams methods
- perhaps add a Radau integrator
- replace the reset() method in step handler interface by init()
(it's a simple rename), and add a similar init() in the events
interface
- fix the mapping between boundary representation/BSP representation
in 2D/3D
could other people add to this list the features they want to have in 3.0 ?
Luc
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [math] release plan for 3.0 ?
Posted by Luc Maisonobe <Lu...@free.fr>.
Le 24/11/2011 10:40, Gilles Sadowski a écrit :
> Hi.
>
>>
>> Issues that I have reported are
>> * MATH-581 (Support for iterative linear solvers): there is now a
>> framework for this feature, as well as two solvers (conjugate
>> gradient, SYMMLQ). While this might be extended with other solvers as
>> well, it could certainly wait (and would not lead to a change in the
>> API). The design of these classes could certainly be improved, but for
>> this, we probably need people to use them... So I suggest we solve
>> this issue for the time being. What do you think?
>
> +1
>
>> * MATH-711 (Merge xxxDistribution and xxxDistributionImpl in package
>> distribution): I'm going to work on this one (should be fairly easy).
>> * MATH-655 (General framework for iterative algorithms): this
>> requires a more thorough discussion, and could probably be tagged as
>> "won't fix", or delayed to a later version.
>
> +1 (leaving open)
>
>> I would very much like to
>> have this discussion on the design of custom stopping criteria again,
>> though.
>> * MATH-699 (inverseCumulativeDistribution fails with cumulative
>> distribution having a plateau): I have posted a new implementation of
>> inverseCumulativeDistribution which does "not really" solve this
>> issue. In short, it would allow us to get rid of methods
>> getDomainUpperBound(double), getDomainLowerBound(double) and
>> getInitialDomain(double). As for the plateau issue itself, I've added
>> an extra test which seems fairly robust, but incurs a slight overhead,
>> so I'm reluctant to include it. Two options here:
>> - clearly state in the Javadoc that the default solver *fails* in
>> the presence of plateau, and be done with it,
>> - add a flag to the constructor, to allow for plateau detection.
>> If you have any opinion on this issue, please state it on the JIRA
>> ticket. Thanks!
>
> +1
>
> The most flexible seems to have two constructors, one with the flag, and
> the other where the flag defaults to false ("do not try to detect plateau"),
> stating the caveat in the Javadoc.
>
>> Gilles, if you want, we can coordinate on MATH-689 and MATH-690.
>
> OK. But first I wanted to make sure that the proposed changes are agreed on.
I have no opinion on this, I let the specialists speak.
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] release plan for 3.0 ?
Posted by Gilles Sadowski <gi...@harfang.homelinux.org>.
Hi.
>
> Issues that I have reported are
> * MATH-581 (Support for iterative linear solvers): there is now a
> framework for this feature, as well as two solvers (conjugate
> gradient, SYMMLQ). While this might be extended with other solvers as
> well, it could certainly wait (and would not lead to a change in the
> API). The design of these classes could certainly be improved, but for
> this, we probably need people to use them... So I suggest we solve
> this issue for the time being. What do you think?
+1
> * MATH-711 (Merge xxxDistribution and xxxDistributionImpl in package
> distribution): I'm going to work on this one (should be fairly easy).
> * MATH-655 (General framework for iterative algorithms): this
> requires a more thorough discussion, and could probably be tagged as
> "won't fix", or delayed to a later version.
+1 (leaving open)
> I would very much like to
> have this discussion on the design of custom stopping criteria again,
> though.
> * MATH-699 (inverseCumulativeDistribution fails with cumulative
> distribution having a plateau): I have posted a new implementation of
> inverseCumulativeDistribution which does "not really" solve this
> issue. In short, it would allow us to get rid of methods
> getDomainUpperBound(double), getDomainLowerBound(double) and
> getInitialDomain(double). As for the plateau issue itself, I've added
> an extra test which seems fairly robust, but incurs a slight overhead,
> so I'm reluctant to include it. Two options here:
> - clearly state in the Javadoc that the default solver *fails* in
> the presence of plateau, and be done with it,
> - add a flag to the constructor, to allow for plateau detection.
> If you have any opinion on this issue, please state it on the JIRA
> ticket. Thanks!
+1
The most flexible seems to have two constructors, one with the flag, and
the other where the flag defaults to false ("do not try to detect plateau"),
stating the caveat in the Javadoc.
> Gilles, if you want, we can coordinate on MATH-689 and MATH-690.
OK. But first I wanted to make sure that the proposed changes are agreed on.
Regards,
Gilles
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [math] release plan for 3.0 ?
Posted by Sébastien Brisard <se...@m4x.org>.
2011/11/26 Phil Steitz <ph...@gmail.com>:
> On 11/23/11 11:28 PM, Sébastien Brisard wrote:
>> Hello,
>>
>> * MATH-699 (inverseCumulativeDistribution fails with cumulative
>> distribution having a plateau): I have posted a new implementation of
>> inverseCumulativeDistribution which does "not really" solve this
>> issue. In short, it would allow us to get rid of methods
>> getDomainUpperBound(double), getDomainLowerBound(double) and
>> getInitialDomain(double). As for the plateau issue itself, I've added
>> an extra test which seems fairly robust, but incurs a slight overhead,
>> so I'm reluctant to include it. Two options here:
>> - clearly state in the Javadoc that the default solver *fails* in
>> the presence of plateau, and be done with it,
>> - add a flag to the constructor, to allow for plateau detection.
>> If you have any opinion on this issue, please state it on the JIRA
>> ticket. Thanks!
> See comments on the ticket. Christian's idea will work - i.e. only
> check if the support is not connected.
>
> Phil
Yes, I do think it's a very good idea. I will commit the new code
(including Christian's work-around) once MATH-703 is resolved, as the
two overlap. Meanwhile, while working on MATH-711 yesterday, I found
some inconsistencies in the implementations. I need to look into it in
more depth, just to make sure I did not misunderstand, and will
report.
Sébastien
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [math] release plan for 3.0 ?
Posted by Phil Steitz <ph...@gmail.com>.
On 11/23/11 11:28 PM, Sébastien Brisard wrote:
> Hello,
>
> Issues that I have reported are
> * MATH-581 (Support for iterative linear solvers): there is now a
> framework for this feature, as well as two solvers (conjugate
> gradient, SYMMLQ). While this might be extended with other solvers as
> well, it could certainly wait (and would not lead to a change in the
> API). The design of these classes could certainly be improved, but for
> this, we probably need people to use them... So I suggest we solve
> this issue for the time being. What do you think?
+1
> * MATH-711 (Merge xxxDistribution and xxxDistributionImpl in package
> distribution): I'm going to work on this one (should be fairly easy).
Nice work!
> * MATH-655 (General framework for iterative algorithms): this
> requires a more thorough discussion, and could probably be tagged as
> "won't fix", or delayed to a later version. I would very much like to
> have this discussion on the design of custom stopping criteria again,
> though.
Probably best to push out, but if possible lay groundwork in 3.0
somehow.
> * MATH-699 (inverseCumulativeDistribution fails with cumulative
> distribution having a plateau): I have posted a new implementation of
> inverseCumulativeDistribution which does "not really" solve this
> issue. In short, it would allow us to get rid of methods
> getDomainUpperBound(double), getDomainLowerBound(double) and
> getInitialDomain(double). As for the plateau issue itself, I've added
> an extra test which seems fairly robust, but incurs a slight overhead,
> so I'm reluctant to include it. Two options here:
> - clearly state in the Javadoc that the default solver *fails* in
> the presence of plateau, and be done with it,
> - add a flag to the constructor, to allow for plateau detection.
> If you have any opinion on this issue, please state it on the JIRA
> ticket. Thanks!
See comments on the ticket. Christian's idea will work - i.e. only
check if the support is not connected.
Phil
>
> Gilles, if you want, we can coordinate on MATH-689 and MATH-690.
>
> Best regards,
> Sébastien
>
>
> ---------------------------------------------------------------------
> 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] release plan for 3.0 ?
Posted by Sébastien Brisard <se...@m4x.org>.
Hello,
Issues that I have reported are
* MATH-581 (Support for iterative linear solvers): there is now a
framework for this feature, as well as two solvers (conjugate
gradient, SYMMLQ). While this might be extended with other solvers as
well, it could certainly wait (and would not lead to a change in the
API). The design of these classes could certainly be improved, but for
this, we probably need people to use them... So I suggest we solve
this issue for the time being. What do you think?
* MATH-711 (Merge xxxDistribution and xxxDistributionImpl in package
distribution): I'm going to work on this one (should be fairly easy).
* MATH-655 (General framework for iterative algorithms): this
requires a more thorough discussion, and could probably be tagged as
"won't fix", or delayed to a later version. I would very much like to
have this discussion on the design of custom stopping criteria again,
though.
* MATH-699 (inverseCumulativeDistribution fails with cumulative
distribution having a plateau): I have posted a new implementation of
inverseCumulativeDistribution which does "not really" solve this
issue. In short, it would allow us to get rid of methods
getDomainUpperBound(double), getDomainLowerBound(double) and
getInitialDomain(double). As for the plateau issue itself, I've added
an extra test which seems fairly robust, but incurs a slight overhead,
so I'm reluctant to include it. Two options here:
- clearly state in the Javadoc that the default solver *fails* in
the presence of plateau, and be done with it,
- add a flag to the constructor, to allow for plateau detection.
If you have any opinion on this issue, please state it on the JIRA
ticket. Thanks!
Gilles, if you want, we can coordinate on MATH-689 and MATH-690.
Best regards,
Sébastien
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [math] release plan for 3.0 ?
Posted by Luc Maisonobe <Lu...@free.fr>.
Le 23/11/2011 23:10, Gilles Sadowski a écrit :
>> [...]
>>
>>>
>>>> could other people add to this list the features they want to have in 3.0 ?
>>>
>>> I think that more important is the review of opened tickets, asking for
>>> people to commit working on them... [Oops, sorry again.]
>>
>> Yes, this was what I meant. sorry to have used the term "feature"
>> inappropriately.
>>
>
>>From issues assigned to me:
> MATH-707 Should not be too hard (search and replace).
> MATH-698 Stuck with CMA-ES; I could use some help (Dietmar?)
> MATH-690 Waiting for comments
Comment added on Jira (OK with your proposed changes)
> MATH-664 Waiting for experts to comment/suggest the best solution
Comment added to Jira (+1 for using QR)
> MATH-637 Could be resolved
>
>>From issues reported by me:
> MATH-413 I think that it could be resolved, but would be happy if someone
> can review the "optimization" package...
I think the package is in good shape now (I still have to add the
adapters, but it will be done soon), so +1 to resolve issue.
> MATH-438 (Obviously)
> MATH-439 One issue not cleared yet I think (related to MATH-413)
> MATH-444 (Trivial)
> MATH-459 (Will it die?!?)
It's close to be resolved now, choosing the most appropriate replacement
exception for each remaining use, using our current available set
(probably mainly using MathIllegalArgumentException and
MathIllegalStateException).
> MATH-488 (ditto)
> MATH-622 The default format is a nuisance but annoying to change as many
> unit tests start to fail
I would propose wont'fix.
Luc
> MATH-666 Should be fairly easy to resolve (unless you are superstitious!)
> MATH-689 A few things left to do (partly related to MATH-690)
>
>
> Best 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] release plan for 3.0 ?
Posted by Gilles Sadowski <gi...@harfang.homelinux.org>.
> [...]
>
> >
> >> could other people add to this list the features they want to have in 3.0 ?
> >
> > I think that more important is the review of opened tickets, asking for
> > people to commit working on them... [Oops, sorry again.]
>
> Yes, this was what I meant. sorry to have used the term "feature"
> inappropriately.
>
>From issues assigned to me:
MATH-707 Should not be too hard (search and replace).
MATH-698 Stuck with CMA-ES; I could use some help (Dietmar?)
MATH-690 Waiting for comments
MATH-664 Waiting for experts to comment/suggest the best solution
MATH-637 Could be resolved
>From issues reported by me:
MATH-413 I think that it could be resolved, but would be happy if someone
can review the "optimization" package...
MATH-438 (Obviously)
MATH-439 One issue not cleared yet I think (related to MATH-413)
MATH-444 (Trivial)
MATH-459 (Will it die?!?)
MATH-488 (ditto)
MATH-622 The default format is a nuisance but annoying to change as many
unit tests start to fail
MATH-666 Should be fairly easy to resolve (unless you are superstitious!)
MATH-689 A few things left to do (partly related to MATH-690)
Best regards,
Gilles
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [math] release plan for 3.0 ?
Posted by Luc Maisonobe <Lu...@free.fr>.
Le 23/11/2011 16:57, Gilles Sadowski a écrit :
> Hi Luc.
Hi Gilles,
>
>>
>> I have had several questions about release plans for 3.0.
>>
>> I feel guilty for not having pushed this version out yet.
>
> "Release early, release often ..." would alleviate this feeling.
> And would reduce the tensions here because much less *new* things would be
> under discussion between releases, because much less new bugs and new
> features accumulate, thus further delaying the next release.
>
> Please, don't take this as a rant; I don't want this thread to become
> another endless and useless discussion. But it is a fact that the current
> release policy is obscure: E.g. the last release has been "self-serving"
> without regards to the implications on the mid-term agenda (i.e. the
> long-overdue release of 3.0)
> Again, don't take it personally; I think that the problem is related to the
> a so-called "user-centric" development model, in a context where we rarely
> see those users who are not developers.
> In the absence of "users-only", the CM developers should, IMHO, foremost be
> working towards making releases that reflect the changing state of the
> library. We could define some metrics that objectively characterize the
> development flux[1]; when some threshol is reached, we *must* start to
> prepare a release, freezing the development and having everyone
> concentrating on issues that block that new release.
>
>> It is not in
>> release shape now and many thing are still ongoing.
>
> Yes, despite several commitments that new features should be deferred to
> after 3.0.
>
>> Typically, a new
>> thread as been started a few hours ago about an important change in the
>> linear algebra API (a needed change, so something important to discuss now).
>
> I agree that it would be nice to fix this issue. But I note that it is not
> *required* to be done before releasing 3.0.
> Many things will surely to need breaking updates fairly soon, and it
> shouldn't be considered harmful to assume that 4.0 could come relatively
> soon after 3.0. IMO, more than 2 years for a new major release belies the
> actual work that has been performed.[2]
OK, if we think we can push this later, this is fine with me.
>
>> As far as I am concerned, here are the points I want to address myself
>> (but if other people want to help, chime in!). I would like to see what
>> other developers have in mind so wa can set up a release plan, and
>> really work toward a release which is past due.
>>
>> My personal tasks are:
>> - finish the adapters wrapping unbounded optimizers into simple bounds
>> optimizers as set up by Gilles, using the two function adapters
>> already available
>> - stabilize Adams based ODE integrators using the
>> MathUtils.linearCombination feature to ensure better accuracy and
>> error estimates in the Nordsieck vectors
>> - perhaps add back the BDF integrator for stiff problems, using the
>> Nordsieck vectors once it has been stabilized for Adams methods
>> - perhaps add a Radau integrator
>> - replace the reset() method in step handler interface by init()
>> (it's a simple rename), and add a similar init() in the events
>> interface
>> - fix the mapping between boundary representation/BSP representation
>> in 2D/3D
>
> It's not polite to tell other people what to work on, but please forgive me:
> Are those issues *blocking*? I suspect that everything that starts with "Add
> ..." is not. Even some improvements that are foreseen could wait for 3.x.
> Part of the policy should be to refrain from wanting "everything, now". In
> fact, I'm pretty sure that by releasing often, we'll be able to offer more
> features in less time.
BDF and Radau can wait. Adams is really needed and the change of reset
to init is trivial, but introduces an incompatibility, so it is much
better to do it now (it's a five minutes work).
>
>> could other people add to this list the features they want to have in 3.0 ?
>
> I think that more important is the review of opened tickets, asking for
> people to commit working on them... [Oops, sorry again.]
Yes, this was what I meant. sorry to have used the term "feature"
inappropriately.
Luc
>
>
> Best regards,
> Gilles
>
> [1] Based on the number of commits, number of opened and resolved issues,
> and so on. [Please add your preferred criteria.]
> [2] And the side-effect is that it makes it difficult for "users-only" to
> actually have a say on individual design changes, as the more time
> passes, the more difficult it will be to reverse a change thay may have
> become intertwined with later ones.
>
> ---------------------------------------------------------------------
> 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] release plan for 3.0 ?
Posted by Gilles Sadowski <gi...@harfang.homelinux.org>.
Hi Luc.
>
> I have had several questions about release plans for 3.0.
>
> I feel guilty for not having pushed this version out yet.
"Release early, release often ..." would alleviate this feeling.
And would reduce the tensions here because much less *new* things would be
under discussion between releases, because much less new bugs and new
features accumulate, thus further delaying the next release.
Please, don't take this as a rant; I don't want this thread to become
another endless and useless discussion. But it is a fact that the current
release policy is obscure: E.g. the last release has been "self-serving"
without regards to the implications on the mid-term agenda (i.e. the
long-overdue release of 3.0)
Again, don't take it personally; I think that the problem is related to the
a so-called "user-centric" development model, in a context where we rarely
see those users who are not developers.
In the absence of "users-only", the CM developers should, IMHO, foremost be
working towards making releases that reflect the changing state of the
library. We could define some metrics that objectively characterize the
development flux[1]; when some threshol is reached, we *must* start to
prepare a release, freezing the development and having everyone
concentrating on issues that block that new release.
> It is not in
> release shape now and many thing are still ongoing.
Yes, despite several commitments that new features should be deferred to
after 3.0.
> Typically, a new
> thread as been started a few hours ago about an important change in the
> linear algebra API (a needed change, so something important to discuss now).
I agree that it would be nice to fix this issue. But I note that it is not
*required* to be done before releasing 3.0.
Many things will surely to need breaking updates fairly soon, and it
shouldn't be considered harmful to assume that 4.0 could come relatively
soon after 3.0. IMO, more than 2 years for a new major release belies the
actual work that has been performed.[2]
> As far as I am concerned, here are the points I want to address myself
> (but if other people want to help, chime in!). I would like to see what
> other developers have in mind so wa can set up a release plan, and
> really work toward a release which is past due.
>
> My personal tasks are:
> - finish the adapters wrapping unbounded optimizers into simple bounds
> optimizers as set up by Gilles, using the two function adapters
> already available
> - stabilize Adams based ODE integrators using the
> MathUtils.linearCombination feature to ensure better accuracy and
> error estimates in the Nordsieck vectors
> - perhaps add back the BDF integrator for stiff problems, using the
> Nordsieck vectors once it has been stabilized for Adams methods
> - perhaps add a Radau integrator
> - replace the reset() method in step handler interface by init()
> (it's a simple rename), and add a similar init() in the events
> interface
> - fix the mapping between boundary representation/BSP representation
> in 2D/3D
It's not polite to tell other people what to work on, but please forgive me:
Are those issues *blocking*? I suspect that everything that starts with "Add
..." is not. Even some improvements that are foreseen could wait for 3.x.
Part of the policy should be to refrain from wanting "everything, now". In
fact, I'm pretty sure that by releasing often, we'll be able to offer more
features in less time.
> could other people add to this list the features they want to have in 3.0 ?
I think that more important is the review of opened tickets, asking for
people to commit working on them... [Oops, sorry again.]
Best regards,
Gilles
[1] Based on the number of commits, number of opened and resolved issues,
and so on. [Please add your preferred criteria.]
[2] And the side-effect is that it makes it difficult for "users-only" to
actually have a say on individual design changes, as the more time
passes, the more difficult it will be to reverse a change thay may have
become intertwined with later ones.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [math] release plan for 3.0 ?
Posted by Phil Steitz <ph...@gmail.com>.
I have been traveling the last couple of days. Will respond tomorrow or Saturday.
Phil
On Nov 23, 2011, at 4:19 AM, Luc Maisonobe <Lu...@free.fr> wrote:
> Hello,
>
> I have had several questions about release plans for 3.0.
>
> I feel guilty for not having pushed this version out yet. It is not in
> release shape now and many thing are still ongoing. Typically, a new
> thread as been started a few hours ago about an important change in the
> linear algebra API (a needed change, so something important to discuss now).
>
> As far as I am concerned, here are the points I want to address myself
> (but if other people want to help, chime in!). I would like to see what
> other developers have in mind so wa can set up a release plan, and
> really work toward a release which is past due.
>
> My personal tasks are:
> - finish the adapters wrapping unbounded optimizers into simple bounds
> optimizers as set up by Gilles, using the two function adapters
> already available
> - stabilize Adams based ODE integrators using the
> MathUtils.linearCombination feature to ensure better accuracy and
> error estimates in the Nordsieck vectors
> - perhaps add back the BDF integrator for stiff problems, using the
> Nordsieck vectors once it has been stabilized for Adams methods
> - perhaps add a Radau integrator
> - replace the reset() method in step handler interface by init()
> (it's a simple rename), and add a similar init() in the events
> interface
> - fix the mapping between boundary representation/BSP representation
> in 2D/3D
>
> could other people add to this list the features they want to have in 3.0 ?
>
> Luc
>
> ---------------------------------------------------------------------
> 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] release plan for 3.0 ?
Posted by Gilles Sadowski <gi...@harfang.homelinux.org>.
On Wed, Nov 23, 2011 at 02:17:24PM +0000, sebb wrote:
> On 23 November 2011 13:41, Gary Gregory <ga...@gmail.com> wrote:
> > As a [math] outsider and curious watcher of the [math] "sub-ML" I can offer
> > the XP mantra: release early, release often. It will never be perfect ;)
I totally agree with this (which was posted, while I was writing my previous
message).
> I think this is a dangerous mantra for Commons, which strives for
> extreme compatibility (to coin a phrase).
This goal is a hindrance in the current state of Commons Math. As I said
several times, it doesn't compare to any other Commons "components" in terms
of code updates (design changes and addition of functionalities).
> > Take care of API breaking changes, release 3, tweak features for 3.1 and so
> > on.
>
> Some API breaks are relatively easy to detect - use Clirr.
> Functional API breaks are a bit harder, though hopefully unit tests
> will reveal these.
>
> The problem with RERO is that it is all too easy to introduce a new
> API which turns out to be faulty.
> This can be difficult or impossible to correct later. There are
> several such examples in the Java libraries.
There were faulty APIs, there are faulty APIs, there will be faulty APIs.
We all hope that code evolves to contain less of those; but preventing
evolution by placing the "compatibility" criterion above everything else is
not going to lead there in the less possible time.
Another 2 cents that make four.
Best,
Gilles
> > 2c,
> > Gary
> >
> > On Wed, Nov 23, 2011 at 4:19 AM, Luc Maisonobe <Lu...@free.fr>wrote:
> >
> >> Hello,
> >>
> >> I have had several questions about release plans for 3.0.
> >>
> >> I feel guilty for not having pushed this version out yet. It is not in
> >> release shape now and many thing are still ongoing. Typically, a new
> >> thread as been started a few hours ago about an important change in the
> >> linear algebra API (a needed change, so something important to discuss
> >> now).
> >>
> >> As far as I am concerned, here are the points I want to address myself
> >> (but if other people want to help, chime in!). I would like to see what
> >> other developers have in mind so wa can set up a release plan, and
> >> really work toward a release which is past due.
> >>
> >> My personal tasks are:
> >> - finish the adapters wrapping unbounded optimizers into simple bounds
> >> optimizers as set up by Gilles, using the two function adapters
> >> already available
> >> - stabilize Adams based ODE integrators using the
> >> MathUtils.linearCombination feature to ensure better accuracy and
> >> error estimates in the Nordsieck vectors
> >> - perhaps add back the BDF integrator for stiff problems, using the
> >> Nordsieck vectors once it has been stabilized for Adams methods
> >> - perhaps add a Radau integrator
> >> - replace the reset() method in step handler interface by init()
> >> (it's a simple rename), and add a similar init() in the events
> >> interface
> >> - fix the mapping between boundary representation/BSP representation
> >> in 2D/3D
> >>
> >> could other people add to this list the features they want to have in 3.0 ?
> >>
> >> Luc
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> >> For additional commands, e-mail: dev-help@commons.apache.org
> >>
> >>
> >
> >
> > --
> > E-Mail: garydgregory@gmail.com | ggregory@apache.org
> > JUnit in Action, 2nd Ed: <http://goog_1249600977>http://bit.ly/ECvg0
> > Spring Batch in Action: <http://s.apache.org/HOq>http://bit.ly/bqpbCK
> > Blog: http://garygregory.wordpress.com
> > Home: http://garygregory.com/
> > Tweet! http://twitter.com/GaryGregory
> >
>
> ---------------------------------------------------------------------
> 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] release plan for 3.0 ?
Posted by sebb <se...@gmail.com>.
On 23 November 2011 13:41, Gary Gregory <ga...@gmail.com> wrote:
> As a [math] outsider and curious watcher of the [math] "sub-ML" I can offer
> the XP mantra: release early, release often. It will never be perfect ;)
I think this is a dangerous mantra for Commons, which strives for
extreme compatibility (to coin a phrase).
> Take care of API breaking changes, release 3, tweak features for 3.1 and so
> on.
Some API breaks are relatively easy to detect - use Clirr.
Functional API breaks are a bit harder, though hopefully unit tests
will reveal these.
The problem with RERO is that it is all too easy to introduce a new
API which turns out to be faulty.
This can be difficult or impossible to correct later. There are
several such examples in the Java libraries.
> 2c,
> Gary
>
> On Wed, Nov 23, 2011 at 4:19 AM, Luc Maisonobe <Lu...@free.fr>wrote:
>
>> Hello,
>>
>> I have had several questions about release plans for 3.0.
>>
>> I feel guilty for not having pushed this version out yet. It is not in
>> release shape now and many thing are still ongoing. Typically, a new
>> thread as been started a few hours ago about an important change in the
>> linear algebra API (a needed change, so something important to discuss
>> now).
>>
>> As far as I am concerned, here are the points I want to address myself
>> (but if other people want to help, chime in!). I would like to see what
>> other developers have in mind so wa can set up a release plan, and
>> really work toward a release which is past due.
>>
>> My personal tasks are:
>> - finish the adapters wrapping unbounded optimizers into simple bounds
>> optimizers as set up by Gilles, using the two function adapters
>> already available
>> - stabilize Adams based ODE integrators using the
>> MathUtils.linearCombination feature to ensure better accuracy and
>> error estimates in the Nordsieck vectors
>> - perhaps add back the BDF integrator for stiff problems, using the
>> Nordsieck vectors once it has been stabilized for Adams methods
>> - perhaps add a Radau integrator
>> - replace the reset() method in step handler interface by init()
>> (it's a simple rename), and add a similar init() in the events
>> interface
>> - fix the mapping between boundary representation/BSP representation
>> in 2D/3D
>>
>> could other people add to this list the features they want to have in 3.0 ?
>>
>> Luc
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
>
>
> --
> E-Mail: garydgregory@gmail.com | ggregory@apache.org
> JUnit in Action, 2nd Ed: <http://goog_1249600977>http://bit.ly/ECvg0
> Spring Batch in Action: <http://s.apache.org/HOq>http://bit.ly/bqpbCK
> Blog: http://garygregory.wordpress.com
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [math] release plan for 3.0 ?
Posted by Gary Gregory <ga...@gmail.com>.
As a [math] outsider and curious watcher of the [math] "sub-ML" I can offer
the XP mantra: release early, release often. It will never be perfect ;)
Take care of API breaking changes, release 3, tweak features for 3.1 and so
on.
2c,
Gary
On Wed, Nov 23, 2011 at 4:19 AM, Luc Maisonobe <Lu...@free.fr>wrote:
> Hello,
>
> I have had several questions about release plans for 3.0.
>
> I feel guilty for not having pushed this version out yet. It is not in
> release shape now and many thing are still ongoing. Typically, a new
> thread as been started a few hours ago about an important change in the
> linear algebra API (a needed change, so something important to discuss
> now).
>
> As far as I am concerned, here are the points I want to address myself
> (but if other people want to help, chime in!). I would like to see what
> other developers have in mind so wa can set up a release plan, and
> really work toward a release which is past due.
>
> My personal tasks are:
> - finish the adapters wrapping unbounded optimizers into simple bounds
> optimizers as set up by Gilles, using the two function adapters
> already available
> - stabilize Adams based ODE integrators using the
> MathUtils.linearCombination feature to ensure better accuracy and
> error estimates in the Nordsieck vectors
> - perhaps add back the BDF integrator for stiff problems, using the
> Nordsieck vectors once it has been stabilized for Adams methods
> - perhaps add a Radau integrator
> - replace the reset() method in step handler interface by init()
> (it's a simple rename), and add a similar init() in the events
> interface
> - fix the mapping between boundary representation/BSP representation
> in 2D/3D
>
> could other people add to this list the features they want to have in 3.0 ?
>
> Luc
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
--
E-Mail: garydgregory@gmail.com | ggregory@apache.org
JUnit in Action, 2nd Ed: <http://goog_1249600977>http://bit.ly/ECvg0
Spring Batch in Action: <http://s.apache.org/HOq>http://bit.ly/bqpbCK
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory
Re: [math] release plan for 3.0 ?
Posted by Phil Steitz <ph...@gmail.com>.
On 11/23/11 2:19 AM, Luc Maisonobe wrote:
> Hello,
>
> I have had several questions about release plans for 3.0.
>
> I feel guilty for not having pushed this version out yet. It is not in
> release shape now and many thing are still ongoing. Typically, a new
> thread as been started a few hours ago about an important change in the
> linear algebra API (a needed change, so something important to discuss now).
>
> As far as I am concerned, here are the points I want to address myself
> (but if other people want to help, chime in!). I would like to see what
> other developers have in mind so wa can set up a release plan, and
> really work toward a release which is past due.
>
> My personal tasks are:
> - finish the adapters wrapping unbounded optimizers into simple bounds
> optimizers as set up by Gilles, using the two function adapters
> already available
> - stabilize Adams based ODE integrators using the
> MathUtils.linearCombination feature to ensure better accuracy and
> error estimates in the Nordsieck vectors
> - perhaps add back the BDF integrator for stiff problems, using the
> Nordsieck vectors once it has been stabilized for Adams methods
> - perhaps add a Radau integrator
> - replace the reset() method in step handler interface by init()
> (it's a simple rename), and add a similar init() in the events
> interface
> - fix the mapping between boundary representation/BSP representation
> in 2D/3D
>
> could other people add to this list the features they want to have in 3.0 ?
I would like to try to get all of the near-term
compatibility-breaking stuff into 3.0, which means focusing on the
issues that change APIs. We have made great progress on this
recently. I would put the linear changes in scope.
There are 43 issues open now with 3.0 fix version. There are still
6 "unscheduled." I was comfortable assigning versions to the 6
remaining by myself. It would be great for everyone to have a look
at these and propose either 3.0, 3.1 or even 4.0 for these
stragglers. Many of the 43 marked for 3.0 are close to complete. I
"assigned" some of them to myself, but that is just to help me keep
track of what I am working on first.
So basically, I would say lets look again at both the 43 and the 6
and see what we can knock off quickly or push out without great fear
of having to make API breaks to resolve.
One additional item that we should be chipping away at is validating
the user guide. Any and all help from the community on this - using
the code in trunk as the basis for validation - would be most
appreciated.
Checkstyle and changes.xml are also in need of some love.
Phil
>
> Luc
>
> ---------------------------------------------------------------------
> 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] release plan for 3.0 ?
Posted by Sébastien Brisard <se...@m4x.org>.
Hi,
as for me, I can only think of new features... probably not the best
time... I'll just name them for the record, to see if people would be
interested
- allow for higher-order Legendre-Gauss integration schemes, and indeed
other Gauss-based integration schemes,
- widen the panel of special functions (I find myself constantly in need
of Bessel functions, for example),
- add new iterative linear solvers (for the time being, only CG and
SYMMLQ are implemented).
On a more practical basis, trying to help for the next release, I've
quickly skimmed through the open JIRA tickets. I'm a little bit
uncomfortable, because I'm very new to this library, and would fear to mess
things up instead of resolving issues. However, I've found at least two of
them I could probably work on quite safely : MATH-677 and MATH-707, if you
think that should be planned for next release.
Also, I can continue working on package distribution, to merge
xxxDistribution and xxxDistributionImpl (someone please answer my post: I
want to check that we agree this should be done!).
Finally, I can start working on the (not-too-long) checkstyle report.
Any other suggestions?
Sébastien