commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From S├ębastien Brisard (JIRA) <>
Subject [jira] [Commented] (MATH-797) Single step integrators
Date Thu, 28 Jun 2012 05:13:43 GMT


S├ębastien Brisard commented on MATH-797:

If I refer to your nice ASCII equation
[Maxima|] 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.

So, are we set to go?
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:
>             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
> 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:!default.jspa
For more information on JIRA, see:


View raw message