[
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
