commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ajo Fod <ajo....@gmail.com>
Subject Re: [math] new feature to allow infinite limits in numerical integration.
Date Sun, 21 Jul 2013 15:04:05 GMT
The patches for Math-994 have been reworked ... slightly better design.

Here is some numerical analysis on the issue:

Laguerre is defined only in [0,+ve Inf]
Hermite is defined in [-Inf,+Inf]

I have two issues with the above:
1: Cant imagine how someone would use AQ. Which means as Gilles noticed,
you can't focus on the hard to converge sections of the integral.
2: If you use the integration without AQ. Any function that has a high
frequency region somewhere off the region where the polynomial focuses, the
integral probably won't converge. For Hermite with its weighting in
e^(-x^2) ... good luck with convergence with say computing CDF of N(0,100)
or for that matter N(100,1).
For an idea look at :
https://en.wikipedia.org/wiki/Gauss%E2%80%93Hermite_quadrature


On Fri, Jun 28, 2013 at 11:13 AM, Phil Steitz <phil.steitz@gmail.com> wrote:

> On 6/28/13 7:44 AM, Gilles wrote:
> > On Mon, 24 Jun 2013 07:43:22 -0700, Ajo Fod wrote:
> >> As I read through the Wikipedia articles on Gauss-Hermite and
> >> Laguerre, I
> >> notice that they are talking about basis functions with
> >> infinity/s in its
> >> domain.  How would this would solve the problem addressed in the
> >> MATH-994
> >> which is to restrict the bounds of the function being integrated
> >> so that
> >> numerical integration is possible.
> >>
> >>
> >>
> http://en.wikipedia.org/wiki/Gauss-Hermite_quadraturehttp://en.wikipedia.org/wiki/Gauss-Laguerre_quadrature
> >>
> >
> > The references rather state that those schemes are indeed used to
> > approximate improper integrals.
> >
> >> In any case,  MATH-994 is a working solution to a major class of
> >> integration problems. A solution that passes the unit tests in the
> >> example is quite desirable.
> >
> > I do not deny that this approach could be useful, but since CM
> > already
> > provides a framework that should accommodate the approaches
> > referred to
> > above, and since we have some initial implementations for some of
> > those
> > schemes (Gauss-Hermite, Gauss-Chebyshev), it not unreasonable to
> > try and
> > reuse (or improve upon) the existing code; at least until you or
> > someone
> > else provides a compelling case where your alternative is indeed
> > better.
>
> +1 What would be really great is some numerical analysis references
> provided indicating which of the methods performs the best.   This
> should not be that hard to research.
>
> Phil
> >
> > [Your use-case is until now reduced to the integral of the density
> > of the
> > normal distribution, which we know in advance is equal to one.]
> >
> >> So, I think the commons would be better of with modifications to
> >> MATH-994 to confirm to the design philosophy than say postponing a
> >> more complex integration scheme is available.
> >
> > The point is indeed that we have something _now_ (cf. above), and
> > helpful
> > work would be to examine its usefulness.
> >
> > Then, if we come to agree that the "change of variable" approach
> > should be
> > implemented in CM, we still need to do it in accordance with the
> > current
> > design of the "o.a.c.m.integration" package (or show that
> > something is wrong
> > or incomplete there and should consequently be modified or removed).
> >
> > Another aspect is to explore the obvious extensions (as you
> > mentioned in the
> > code comments) of the code which you propose, i.e. how it can be
> > made most
> > useful by increasing its flexibility.
> > In the case of "InfiniteIntegral", this could include:
> > * Providing suggestions on how to extend the existing framework so
> > that users
> >   can easily pick what they need.
> > * Working out the details of generalizing to other types of
> > improper integrals
> >   (sometimes this allows to readily figure out how to improve the
> > design).
> > * Showing how to apply the code in non-trivial examples
> > (eventually to be
> >   included in the userguide).
> >
> >> The code can always be
> >> deprecated once a better implementation is available.
> >
> > Agreed, but in this case, another road is clearly visible and we
> > have to
> > try and keep everything consistent. It doesn't make sense, from a
> > design
> > and maintenance viewpoint, to postpone this work to a later time.
> >
> >> (You don't have
> >> to do it on my account, I already have what I need.)
> >
> > If not even you are going to use this code, what good would it do
> > to CM?
> > As I tried to explain above, in order to be useful to a wide range of
> > users, CM must provide code that is flexible. We all have to try
> > hard not
> > to consider a general purpose library as a repository for
> > disparate ad-hoc
> > code snippets.
> >
> >
> > Best regards,
> > Gilles
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > For additional commands, e-mail: dev-help@commons.apache.org
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message