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
