On 6/23/13 3:14 PM, Gilles wrote: > On Sat, 22 Jun 2013 22:36:04 -0700, Phil Steitz wrote: >> On 6/21/13 5:17 PM, Ajo Fod wrote: >>> I've submitted a patch for the issue (see MATH-994). This will >>> allow users >>> to integrate functions with infinity as one of the bounds. >>> >>> Cheers, >>> Ajo Fod. >>> >> Thanks for bringing the discussion to the dev list, Ajo. As Gilles >> said on the ticket, its a little easier to have a discussion here >> than on JIRA tickets, so We usually start the discussion here about >> whether or not a new feature makes sense and, if so, how to >> implement it. >> >> I am +1 for adding support for improper integrals. I am not a >> numerical integration expert, however, so can't definitively >> evaluate the merits / drawbacks of the change of variable approach >> in the patch. My intuition tells me though that the other >> approaches mentioned in the javadoc reference in the patch [1] might >> be more robust. Does anyone have experience or references that can >> help us here? > > Which other approaches, exactly?
The ones referred to in the Wikipedia article cited in the javadoc patch: http://en.wikipedia.org/wiki/Gauss-Hermite_quadrature http://en.wikipedia.org/wiki/Gauss-Laguerre_quadrature > > I want to mention that issue: > https://issues.apache.org/jira/browse/MATH-797 > I.e. Sébastien Brisard provided the initial code which I adapted to > create the contents of the package > o.a.c.m.analysis.integration.gauss > Sébastien's implementation contains additional code (Gauss-Chebyshev, > Gauss-Hermite, Gauss-Kronrod) that is not (yet) part of Commons Math. > It would be wasteful to not use it (but it is also a fair amount of > work to adapt the code, as the design was substantially modified to > get to what is in CM now). > > Just saying that if those other quadrature schemes are useful to > compute some improper integrals, they should probably be included > first > (this requires implementing appropriate "Factory" classes, cf. the > mentioned package). > > Even if we would be satisfied with the algorithm proposed in > MATH-994, > I'd still wonder whether the code could not be designed similarly to > what was done in the above-mentioned package rather that an unrelated > class. +1 to all points above. Phil > > Gilles > >> >> Phil >> >> [1] http://en.wikipedia.org/wiki/Numerical_integration > > > --------------------------------------------------------------------- > 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
