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
flexibility.
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
"o.a.c.m.fitting.leastsquares").
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.
Regards,
Gilles
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
