----- "Phil Steitz" <phil.ste...@gmail.com> a écrit :
> On Wed, Jan 26, 2011 at 2:21 PM, Luc Maisonobe <luc.maison...@free.fr>
> wrote:
> > There are only two issues left in Jira for 2.2.
> >
> > I think MATH-488 could be considered resolved as the class has been
> > deprecated as requested 5 days ago.
> >
> > Concerning MATH-487, I understood we are going to keep
> > ConvergenceException as a base class for a bunch of lower level
> > exceptions. Who volunteers for this task and on what time frame ?
> >
> I will create JIRA and post a patch with the new exceptions this
> weekend.
>
> > Apart from these Jira issues, Phil wanted to remove binary
> > incompatibilities. We said the incompatibilities in ODE could not
> be
> > removed as they are internal only and required to fix bugs. We did
> not
> > conclude on FunctionException/DerivativeException.
>
> You convinced me (twice actually, sorry :) that there is no immediate
> user impact due to FunctionEvaluationException changes. One thing
> that I did not mention before is that for UnivaritaRealFunction
> specifically, the new setup implies that *all*
> UnivariateRealFunctions
> are going to be user-defined functions. I am not sure that this is
> strictly true (aren't there some places where [math] code creates
> UnivariateRealFunctions?) nor is it IMO a good constraint to force.
This is a good point I overlooked. There are several implementations of
UnivariateRealFunction in [math], typically used in root solvers. As an
example, the following code comes from the EventState class in
o.a.c.m.ode.events package:
final UnivariateRealFunction f = new UnivariateRealFunction() {
public double value(final double t) throws MathUserException {
try {
interpolator.setInterpolatedTime(t);
return handler.g(t, interpolator.getInterpolatedState());
} catch (EventException e) {
throw new MathUserException(e);
}
}
};
This instance is used for root solving and there is a catch corresponding to
the throw
shown above. The catch clause is:
} catch (MathUserException mue) {
final Throwable cause = mue.getCause();
if ((cause != null) && (cause instanceof EventException)) {
throw (EventException) cause;
}
throw mue;
}
And in fact the if statement is always true so the underlying event exception
is recovered.
This code means that when the new exception is used internally, it use in fact
only
used as a wrapper and unwrapped on exit. So whatever the exception is, we adapt
this
code and from a user standpoint nothing changes.
I agree tagging this exception "User" seem strange here, but it could be
replaced by any
other unchecked exception. We simply use the user API internally just because
it is
available and it seemed simpler to comply to it.
> Is there a way that we can avoid the change to
> UnivariateRealFunction?
Avoiding this change means we keep a checked exception and hence it goes up
in solvers, integrators, optimizers ...
>
> Regarding DerivativeException do the changes also require no user
> code
> changes? Why do these changes have to be in 2.2? Also, ask the same
> question as above about DerivativeException: does the underlying
> function have to be a user-defined function?
In this case, yes it is only for user-defined objects, there are no internal
use of
this yet. the reasons for puttingit in 2.2 is the same as
FunctionEvaluationException,
it helps transition towards 3.0.
>
> The was still a
> > question about removing binary incompatibilities in the
> optimization
> > framework. What do we do about this ?
>
> I will revert the optimization breaks if no one beats me to it. It
> is
> clear what needs to be done from the svn diffs (look at for example,
> at the log of AbstractLeastSquaresOptimizer
> <http://s.apache.org/VZb>). We just need to remember to reapply the
> FastMath (MATH-375) changes. I will have time to work on this this
> weekend.
Great. I will not have much time this week end.
best regards,
Luc
>
> Phil
> >
> > Luc
> >
> >
> ---------------------------------------------------------------------
> > 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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
