commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Phil Steitz <>
Subject Re: [math] new feature to allow infinite limits in numerical integration.
Date Fri, 28 Jun 2013 18:13:00 GMT
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.
> 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.

> [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:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message