commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gilles <>
Subject Re: [math] UnivariateIntegrator stop conditions
Date Mon, 04 Aug 2014 12:04:52 GMT
On Mon, 04 Aug 2014 14:41:24 +0400, Alexander Nozik wrote:
> The univariate integrator class provides iterative integration
> procedure. It throws exception if the number of evaluations is larger
> than given number. The problem arises when one is limited by some
> performance issues and wants to minimize the number of evaluations
> even at the expense of accuracy. So for example I need to calculate 
> an
> integral with best possible accuracy with limited number of
> evaluations (and check the accuracy afterwards).

I agree that the current design doesn't care for that case.

> I can't do that
> because if UnivariateIntegrator throws the exception, I can not 
> access
> the result. Also it does not make sense why the accurasy is provided
> in the constructor and maximum number of evaluations is the parameter
> of integrate method.

These are decisions made a while back; I recall that there were some
fuzziness as to which parameters should go where.
It was supposedly a trade-off between robustness, efficiency and

The design could be challenged now, provided we can replace it with
something comprehensive. We could draw inspiration from the redesign
of the least-squares fitting implementation (see package

> Of course one could use the GaussIntegrator, but it does not
> implement UnivariateIntegrator class, so if one needs to use these
> integrators interchangeably (I do need), than the only option is to
> write some wrapper class.
> It would be good to have a default UnivariateIntegrator wrapper for
> GaussIntegrator.

"GaussIntegrator" is a building block for "IterativeLegendreIntegrator"
(that implements the "UnivariateIntegrator" interface).
It's a self-consistent implementation of a standard algorithm.
I don't think it would be a good idea to clutter it with methods which
you just said that are not flexible enough.

> Also perhaps it makes sense to move maximum
> evaluations to the constructor.

How would that help you?

> I believe this question has already been discussed somewhere last
> year but I can't remember the answer.

See above, and the "dev" ML archive.

You are most welcome to propose a new integration framework.


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

View raw message