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

{quote}
If I refer to your nice ASCII equation
{quote}
[Maximahttp://maxima.sourceforge.net/] is a very faithful friend of mine...
I now remember why I implemented {{GaussLegendreFactory}}, {{GaussChebyshevFactory}}, and
the likes, instead of one big factory qs you suggested. The reason for this is that npoint
rules are computed recursively: you need first to compute the (n1), (n2), ... 1point rules.
I therefore cached all previously computed rules, which can make one single factory messy,
because you would need one cache for each rule. However
* I am not sure that caching is indeed necessary: computing a new rule will presumably not
occur too often in particular applications, and we can probably allow for the CPUcost,
* we could also think of a factory method which would take the (n1) point rule and return
the npoint rule.
* the two approaches (one big factory vs. multiple factories) is anyway tractable: we can
still define multiple factories, and have one {{GaussIntegratorFactory}} which holds singleton
references to each of these specific factories. I have to say I find your idea of one big
single factory very neat.
{quote}
So, are we set to go?
{quote}
I think so. I guess you will start with implementing the stripped down GL integrator, where
all points and weights have been precomputed (not computed onthefly), so you are not likely
to have the above problem.
> 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
