[ https://issues.apache.org/jira/browse/MATH-797?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13402854#comment-13402854 ]
Sébastien Brisard commented on MATH-797:
----------------------------------------
{quote}
If I refer to your nice ASCII equation
{quote}
[Maxima|http://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 n-point rules are computed recursively: you need first to compute the (n-1), (n-2), ... 1-point 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 CPU-cost,
* we could also think of a factory method which would take the (n-1) point rule and return the n-point 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 G-L integrator, where all points and weights have been precomputed (not computed on-the-fly), so you are not likely to have the above problem.
> 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