[ https://issues.apache.org/jira/browse/MATH797?page=com.atlassian.jira.plugin.system.issuetabpanels:commenttabpanel&focusedCommentId=13287998#comment13287998
]
Sébastien Brisard commented on MATH797:

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 singlestep/iterative: the next iteration
has to have access to internal calculations done in the previous iteration.
* Gausslike 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 GaussLegendre 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 Gausslike 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: MATH797
> URL: https://issues.apache.org/jira/browse/MATH797
> 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 usecases 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
