commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Phil Steitz <phil.ste...@gmail.com>
Subject Re: [math] 2.2 compatibility issues
Date Sun, 02 Jan 2011 23:33:34 GMT
On Sun, Jan 2, 2011 at 5:50 PM, Luc Maisonobe <Luc.Maisonobe@free.fr> wrote:

> 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:
> <http://markmail.org/message/f4tst3fg6vwrjkuz>). 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
> o.a.c.m.ode.events 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!

Phil

>
> Luc
>
> >
> > Thanks for pointing this out.
> >
> > best regards,
> > Luc
> >
> >>
> >> 4) Incompatible changes in the optimization package.
> >>
> >> Thanks in advance!
> >>
> >> Phil
> >>
> >
> >
> > ---------------------------------------------------------------------
> > 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
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message