commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Luc Maisonobe <>
Subject Re: [math] puzzled by generics in root solvers
Date Thu, 07 Jul 2011 13:40:19 GMT
Le 07/07/2011 14:41, Gilles Sadowski a écrit :
> 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.

At least it points towards have a separation from raw solvers.

>>> 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?

This is what was intended at first. Up to 2.2, users could not choose 
the solver, it was always Brent that was used and dirty tricks had to be 
done in the events detection to circumvent problems when the wrong side 
was returned. Now users can choose the solver, so we considered a few 
days ago that only bracketing solvers should be allowed. However, this 
is only due to an internal implementation. In fact, at user level there 
should not be any requirements for a bracketing solver, and in fact even 
if the user provides a bracketing solver we *will* reconfigure it to 
make sure the proper side is selected according to integration direction 
(forward or backward integration). So I considered adding the wrapper 
and let the user choose any solver he wants.

This is however internal code, so for this specific case, we can use any 
solution, be it a wrapper added before solving or a refinement after 


>>> 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:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message