commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gilles Sadowski <gil...@harfang.homelinux.org>
Subject Re: [math] puzzled by generics in root solvers
Date Thu, 07 Jul 2011 12:41:18 GMT
Hi.

> > We also do not have a clear separation between algorithms that take a
> > bracket (e.g. "BrentSolver") and those that don't (e.g. "NewtonSolver").
> > If the "solve" methods called by the user contains more parameters than
> > needed by the algorithm implemented in the instance, they will be
> > ignored. [In some sense, this is even worst than the bracketing "enum"
> > case. However, in both cases we could maybe assume that the user has a
> > minimal knowledge of the concept implemented in the class which he is
> > using.
> 
> Although this could be solved by adding very clear documentation, I
> think it would be about the worst thing we could do. Ignoring what
> the user asks for will confuse many users. While I don't like it
> that much, in this case it would be better to use a fallback
> bracketing solver to guarantee the solution that the user asked for.

I think that there is a misunderstanding here:
For the "bracketed solutions" use case, it will always be what the user
requested: Either the call to "solve" specify a "solutionType" parameter
and the bracketing will be used to provide the corresponding answer, or the
call to "solve" does not specify a "solutionType" and the solution of the
original algorithm will be returned.

In "NewtonSolver", the interval bounds passed to "solve" are used to compute
the mid-point that is then used as the "startValue" of the solver. So it's
not to be interpreted as a bracket.
Maybe a safer alternative would be to throw an exception instead, as you
suggest below. However this implies that the user must compute the starting
point himself (i.e. we deprive him from syntactic sugar in this case...).

> 
> > And, again, not specifying a parameter (in the call to "solve")
> > won't do any harm ;-).]
> 
> Sure. That is always a good idea, as it keeps backward compatibility.
> 
> > Yes, this is probably a good point.
> > It could be solved by adding a "setBracketingSolver" method to the base
> > class. If not explicitely specified, which one should be the default?
> 
> Of the secant-based methods Pegasus claims the fastest convergence
> rates, so I would suggest that one. If the Brent solver is
> bracketing, as you suggest, then it should probably be adapted to
> implement the allowed solutions as well, and then maybe that one
> could be used.

This reminds me of a discussion we had some time ago about naming classes
according to well-known algorithms but slightly "improving" the
implementation. [It was about "LevenbergMarquardt".]
Is the choice of "..._SIDE" part of the algorithm's standard implementation?
In "Brent" it is not, and I think that it would be misleading to merge this
functionality within the core algorithm. IMHO, this would also point towards
the "refine" route.

> > However, if we do want to provide the utility, maybe that it should be
> > considered as such and _not_ as a solver by itself. E.g. some method
> > "refine" in some utility class:
> 
> This has the downside of having to handle the different cases in
> very place we use them. For instance, the ODE solver's state event
> detection would have to check whether it is a bracketing solver, and
> if not, use the refine method. Other uses would get a duplication of
> that block of code.

[I haven't looked at the ODE part of CM yet, so my comment here might be
completely off base.]
It seems that the ODE routines need a bracketing solver where you can
specify the location of the root. If this is so, it looks like it is
_inside_ the ODE code that it must be made sure that solution is the
correct one, and if not, "refine" it ("LEFT" or "RIGHT" according to the
needs of the procedure.
Even safer would be to only allow a "BracketingSolver" to be passed to the
ODE code. Why bother allowing an algorithm that do not guarantee the needs
of the ODE routines?

> > In principle, you are right.
> > But in practice, we'd add an efficiency penalty to the algorithm by
> > checking for unused arguments instead of simply ignoring them and
> > assuming that the user knows what he does.
> 
> I think we should make sure that if an argument can syntactically be
> provided, that it should be taken into account. If it can't be taken
> into account, an exception should be thrown, or the method should
> not have an overload with that argument. So, non-bracketed solvers
> should either:
>  - not have an overload to specify the allowed solutions
>  - have the overload and implement the desired behavior (fallback
>    bracketed solver)
>  - have the overload and throw exceptions if they don't support it.
> 
> Once again, ignoring a parameter may make the user think that (s)he
> gets solutions as requested, while the solutions don't actually
> guarantee this. This is very confusing for end users and will most
> likely result in bugs, especially from users who are not that
> familiar with the CM functionality.

Well, there are probably many things you can use in CM that will return a
spurious result if not called properly (e.g. not taking into the
assumptions stated in the documentation like for the "solve" overriding in
"NewtonSolver").

> 
> >> Question: what other solvers that are available maintain a bracketed
> >> solution, besides the secant-based methods?
> >
> > "BrentSolver" (referring to Luc's nice ASCII art picture a few posts
> > ago).
> 
> I'm confused by your reference to the ASCII art picture. From the
> picture it can not be concluded whether the BrentSolver is
> bracketing or not. Also, the picture does not show all solvers, I
> think. It seems to only show enough examples to indicate the
> hierarchy. What is the relation between your answer and the picture?

My bad; I hadn't recalled the picture correctly.

> 
> If the BrentSolver, and maybe other solvers, are bracketing, they
> should probably also implement the different allowed solutions
> directly.

As said above, I'm rather of the opposite opinion. :-}


Regards,
Gilles

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message