Hi.
> > I need some clarifications before embarking into the clean-up of that
> > package.
> >
> > The "integrate" method of interface "UnivariateRealIntegrator" is defined
> > as:
> > double integrate(UnivariateRealFunction f, double min, double max)
> > throws ConvergenceException, MathUserException,
> > IllegalArgumentException;
> >
> > As a comparison, a "solve" methods from the solver interface:
> > double solve(int maxEval, FUNC f, double min, double max);
> >
> > (1) Is the notion of "iteration" for the integrator similar to the number of
> > evaluation for the solvers? In other words, shall we now pass the (minimal
> > and maximal) numbers of iterations as parameters of "integrate"?
> >
> I can't remember why we decided to move away from having the maximum
> number of iterations a property of the solver, [...]
In the case of solvers, we suppose that the comparison of the efficiency of
different solvers is based on the number of calls to the function to be
solved (if the function evaluation is relatively slower than the solver code
itself). The number of iterations is only an implementation detail of the
solver code.
> but the same concept
> does apply to integrators. So to be consistent, we should probably
> make that change.
Which concept?
Alternative 1:
Do we have to consider only the number of evaluations, thus that
for the integrators too, the number of iterations is an implementation
detail (i.e. not allowing the user to set it)? [Change of semantics (and
interface).]
Alternative 2:
Is the number of iterations still a user-defined property in the case of
integrators but it should be passed in the call to "integrate". [Change of
interface.]
Or did you mean yet something else?
>
> > (2) Should there also be a limit on the number of function evaluations?
> >
> I think that would be a good enhancement here and actually for the
> solvers as well. We need to think carefully though about the burden
> that this places on implementations.
As reminded above, changing from an iteration-based to an evaluation-based
criterion makes it possible to uniformly set a time limit when solving or
optimizing a function.
I started that thread because I'm not so sure that it is useful for
integrators.
In other words, is it a common pattern where one would say: "I want to
compute this integral in less than n evaluations of the function." ?
> > (3) We have here an occurrence of "ConvergenceException" whereas the
> > potential problems that can actually occur are that the number of iterations
> > is too low or too high.
> > I thus propose to use the existing "MaxCountExceededException" for "too many
> > iterations". Shall I create a "MinCountNotReachedException" for "too few
> > iterations"?
>
> Where do we throw on too few iterations? Generally that is not an
> issue. [...]
See the doc of "setMinimalIterationCount" in "UnivariateRealIntegrator".
> In any case, per my previous post on ConvergenceException, I
> see MaxIterationsExceeded as logically a subclass of
> ConvergenceException.
In reply to that post, I reminded that there exists a
"MaxCountExceededException" that is a sub-class of
"MathIllegalStateException".
"MaxCountExceededException" is thrown by the very low-level "Incrementor"
class, and so it cannot be a subclass of a high-level concept such
"ConvergenceException".
A possible way out of this dilemma could be that "ConvergenceException"
objects will wrap a "cause" exception. Hence we could have:
public class ConvergenceException extends MathRuntimeException {
private MathRuntimeException cause;
public ConvergenceException(MathRuntimeException cause) {
this.cause = cause;
}
// ...
}
and
public class MaxIterationExceededException extends ConvergenceException {
private final int max;
public MaxIterationExceededException(MaxCountExceededException cause) {
super(cause);
max = cause.getMax();
}
// ...
}
> Another logical alternative would be to define
> an enum characterizing the failed convergence in ConvergenceException
> as diverge to +inf, diverge to -inf, diverge to NaN, max iterations
> exceeded and add a property to ConvergenceException holding this
> value. I favor separating out the subclasses because they can then
> carry more information [...]
+1 for subclasses.
> such as, for the divergence subclasses, the
> iteration number where the out of range value occured and for the max
> iterations exceeded what the max is.
Indeed; cf. above for the "max" example.
> >
> > (4) Is it OK to pass accuracy parameters as arguments to the constructors
> > (as is done for the solvers)?
> >
> Yes, but I am wondering why this is different from the maxIterations.
> Why are the accuracy properties properties of the solver and max
> iterations a method parameter? To be consistent, we should probably
> move all the way to the procedure style and pass these parameters to
> the solve/integrate methods as well.
With this comes some subjectivity.
I tend to see the accuracy properties as tied to the solver code while the
number of function evaluations is more function-dependent.
Hence -1 for a full procedure-style (although admittedly more consistent
if we only consider syntactic uniformity).
Gilles
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
