[
https://issues.apache.org/jira/browse/MATH-797?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13287998#comment-13287998
]
Sébastien Brisard commented on MATH-797:
----------------------------------------
I don't really follow. Are you proposing to duplicate all existing integrators
(one single step, one adaptative implementation)? The immediate answer would be
to decide that all integrators are single step, and define one iterative
integrator, which would be provided with a single step integrator at the time
of construction. But that does not work (see below).
I think that we can't have one single policy for all integrators
* trapezoid, Simpson and Romberg integrators are iterative in nature, and IIRC,
there are some clever optimisations which prevent the separation
single-step/iterative: the next iteration has to have access to internal
calculations done in the previous iteration.
* Gauss-like integrators are in my view single step integrators. Indeed, I
think that people use Gauss integration schemes in order to have absolute
control on the number of operations which are carried out. This goes opposite
to the current implementation of these integrators in CM3.
So, to sum up, I think that if we were to create a second interface, maybe we
could think about creating a GaussIntegrator, dedicated to Gaussian integration
schemes. These schemes would not be iterative, like what is proposed in this
ticket. All other existing integrators would remain unchanged.
By the way, the maximum number of integration points in the Gauss-Legendre
scheme is limiting. I have some reliable (hi accuracy) code to compute the
points and weights at any order. Also, I have an implementation for other
Gauss-like schemes, which I'm happy to contribute if we can agree on a common
interface with Gaussian integration schemes (which I find very useful and
efficient).
> Single step integrators
> -----------------------
>
> Key: MATH-797
> URL: https://issues.apache.org/jira/browse/MATH-797
> Project: Commons Math
> Issue Type: Wish
> Affects Versions: 3.0
> Reporter: Gilles
> Assignee: Gilles
> Priority: Trivial
> Fix For: 3.1
>
>
> CM assumes that the user wants to integrate a complex function on a large
> interval, so the large interval has to be subdivided into many subintervals.
> CM does the partition, and performs convergence checks, using an iterative
> approach.
> However, if the function is smooth enough, no subdivision of the integration
> interval is required. Those use-cases could benefit from the efficiency gain
> of not performing a convergence check.
> The proposal is to provide a new interface "UnivariateSingleStepIntegrator":
> {code}
> interface SingleIntervalIntegrator {
> /**
> * Method for implementing a single interval integration.
> * There is no convergence checks because it is not iterative.
> *
> * @param f Function to integrate.
> * @param lower Lower bound of the interval over which to integrate.
> * @param upper Upper bound of the interval over which to integrate.
> * @return the integrated value.
> */
> double integrate(UnivariateFunction f,
> double lower,
> double upper);
> }
> {code}
> In effect, the implementation of the above "integrate" method of a new
> "LegendreGaussIntegratorSingleStepIntegrator" would the equivalent of
> "stage(1)" in the current "LegendreGaussIntegrator".
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
