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.
[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
