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.ste...@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-unsubscr...@commons.apache.org > > For additional commands, e-mail: dev-h...@commons.apache.org > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > >
