On Thu, Jan 27, 2011 at 4:04 AM, <luc.maison...@free.fr> wrote:
>
> ----- "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 ...
>
OK. But now that we have detected an "aroma" around unilaterally
making UnivariateRealFunction throw Math*User*Exception, I wonder if
there is a way to introduce an unchecked parent that gets us out of
this. We may want to reserve the right to do this in 3.0, so the "head
start" in 2.2 might be a head start to nowhere, unless we find a way
to fix it in 2.2 (or you convince us that the current setup is an OK
long-term solution).
Phil
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
