On Wed, Jan 26, 2011 at 7:23 AM, Gilles Sadowski <gil...@harfang.homelinux.org> wrote: > 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, but the same concept does apply to integrators. So to be consistent, we should probably make that change.
> (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. > (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. In any case, per my previous post on ConvergenceException, I see MaxIterationsExceeded as logically a subclass of ConvergenceException. 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 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. > > (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. Phil > > Regards, > Gilles > > --------------------------------------------------------------------- > 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
