commons-issues mailing list archives

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

    [ 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

       

Mime
View raw message