commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Luc Maisonobe <>
Subject Re: [math] 2.2 compatibility issues
Date Sun, 02 Jan 2011 20:09:38 GMT
Hi Phil,

Le 02/01/2011 19:01, Phil Steitz a écrit :
> The clirr report run from the current MATH_2_X branch is, as expected,
> problematic.  To get 2.2. out, we need to agree on what breaks we are going
> to allow and what we are going to fix.   Here is a first cut and proposal
> for some immediate fixes that I would appreciate feedback on.
> 0)  The improvements to the distributions classes to add characteristic
> support and positive mass domains have added some new methods to interfaces
> and new abstract methods to abstract classes.  I apologize for not spotting
> this in initial patch reviews or being clear in discussion of the
> features.   I think we can keep the functionality without introducing the
> compatibility breaks by removing the added methods from interfaces /
> abstract classes.  The only painful part is the nice solution for caching
> numerical characteristics that will have to be repeated in the
> implementation classes that need it.  I would like to proceed with these
> changes in the 2.2 branch if others are OK with it.
> 1) Removed superclasses in the exception hierarchy.  I am OK leaving these
> as is.
> I don't know what, if anything, to do about the following:
> 2) Changed return type of interpolate in BicubicSpline.
> 3) Incompatible changes in the ode package.

I'll look at it tomorrow. I have tried to restrict the changes to a
minimum, pushing more complete changes to 3.0.
ODE interfaces are split into two groups: the interfaces that are used
so users can switch from one solver to another and interfaces that
represent user problems and callbacks. There is a really tiny chance
users would have implemented their own solvers (i.e. implemented
interfaces of the first group) as these are complex interfaces with lots
of features. For these interfaces, I think we can accept changes if any.
Interfaces of the second group should absolutely be kept as stable as
possible since users *must* implement them by themselves.

I will check if there are changes in the first and in the second group.
If their are changes in the second group, I will remove them and if
there are changes in the first group, I will ask on the list what we
should do.

Thanks for pointing this out.

best regards,

> 4) Incompatible changes in the optimization package.
> Thanks in advance!
> Phil

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message