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 22:50:03 GMT
Le 02/01/2011 21:09, Luc Maisonobe a écrit :
> 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.

I found a few minutes and fortunately there are very few problems with ODE.

There is one error with DerivativeException superclass, which we
discussed in mid-November (thread is here:
<>). So this problem was
expected, is explained and we concluded that the change was worth doing
fro preparing users a smoother patch towards 3.0.

The other error is a changed arguments list in
EventState.reinitializeBegin introduced as of r1002827. This change was
needed to solve issue MATH-421. The EventState is public in the package so that AbstractIntegrator from the upper
level package o.a.c.m.ode can use it. However, it does not belong to the
public interface of the library, it is used only internally to wrap
users provided EventHandler implementation and preserve their state
during ODE integration. So the change is an internal change and does not
affect user code at all.

I would consider we can keep these two changes.


> Thanks for pointing this out.
> best regards,
> Luc
>> 4) Incompatible changes in the optimization package.
>> Thanks in advance!
>> Phil
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

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

View raw message