On Sun, Jan 2, 2011 at 5:50 PM, Luc Maisonobe <luc.maison...@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-unsubscr...@commons.apache.org > > For additional commands, e-mail: dev-h...@commons.apache.org > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > >
