Hi.
On Mon, 1 Jul 2013 10:50:19 -0700, Ajo Fod wrote:
If you wanted to use the Math 3 codebase in AdaptiveQuadrature, you'd
compute the calculations of Q1 and Q2 with something else. I'm not
entirely
familiar with the apache Math codebase [...]
You could file a "wish" request as a Commons Math's user. Then, if
and when some regular contributor finds some time, he will try to
implement the functionality.
However, when you provide a patch for inclusion in the codebase, it
is necessary to be more informed about similar functionality that
would already exist in Commons Math, so that the contribution can be
merged gracefully (i.e. with "minor" changes which committers will
happily perform for you).
You are welcome to ask questions in order to be able to contribute.
As I tried to explain in more than one way, modifying your code is
far from being trivial. If the committer has to figure out how to
change/adapt/comment a significant part of the contribution, it
ends up being easier to implement the feature from scratch!
Each of the tests in the patch is integrating a UnivariateFunction in
[-1,1]. Infinity.wrap(fn) just provides that UnivariateFunction. [In
the
patches for MATH-995 the InfiniteIntegral was replaced by
Infinity.wrap()
]. So, if you are saying that the intent of
IterativeLegendreGaussIntegrator (refered to as LGQ) was not to
integrate
this kind of UnivariateFunction in [-1,1], ... what kind of
univariate
function would that be?
Again, it is not just any UnivariateFunction, it is a function that
maps the [-inf, +inf] interval into [-1, 1].
It seems that the Gauss-Legendre quadrature is not appropriate for
this. This is probably because the sample integration points do not
cover the _whole_ interval: for the 10-point rule, the first point
is at
-0.9739065285171717
and the last point is at
0.9994069665572084
The interval in the original variable is thus [-18.908, 842.872]. This
is far from adequate for integrating a Gaussian function with
sigma=1000.
[And, as Phil pointed out from the outset, I suspect that the change of
variable also introduces numerical errors since the result becomes
worse
when increasing the number of sample points. Increasing the requested
precision leads to a prohibitive increase of the number of evaluations,
without improvement of the accuracy. In itself it is not sufficient to
indicate a bug of "IterativeGaussLegendre"; it could simply be a
limitation inherent to the algorithm.]
If it is indeed supposed to do the integration,
then AQ clearly does a better job.
Adaptive methods are certainly useful, but we need examples where
its usage is appropriate. It is _not_ indicated for the improper
integral of a Gaussian (even though it indeed performs better than
Gauss-Legendre).
So, why does LGQ fail here? It is probably that the Adaptive division
of
the integration domain (as opposed to the uniform division with LGQ)
gives
AQ the critical edge. The test you have for LGQ so far are pretty
well
behaved.
Cf. above.
AFAIU, the problem reported by MATH-995 is not a bug in
"IterativeLegendreIntegrator": it correctly integrates a Gaussian
with a large sigma _if_ the integration interval is "large enough"
(cf. unit test referred to in my comment to MATH-995).
Unless someone can point to something I'm missing in MATH-995, I'll
close that issue.
Summary: I'm demonstrating a clear bug/inefficiency with LGQ
I don't agree with that statement.
"IterativeGaussLegendre" produces the correct answer (at 1e-6
accuracy) in less than 60 function evaluations. To achieve the same,
your code needs 995 evaluations.
and providing
you with an alternative that is more accurate.
Cf. above (and my previous post), about how to contribute to
Commons Math.
Please open a new feature request.
Regards,
Gilles
On Mon, Jul 1, 2013 at 8:22 AM, Gilles <gil...@harfang.homelinux.org>
wrote:
Hi.
I just noticed your request to write the algorithm along the lines
of the
wikipedia article.
The only major difference between my code and the article on
Wikipedia is
that I found it necessary to move the recursive stack in into a
data
structure to avoid a StackOverflowException when the non polynomial
curvature is concentrated in a corner of the domain of integration.
Notice
that the Stack objects stores a Stack of limits of integration.
There is a misunderstanding: I'm referring to the "high-level"
description of the algorithm that is the separation of concerns
between the quadrature method and the adaptive process. Your code
mixes the two. Moreover, it does not reuse any of the quadrature
schemes already implemented in CM, but implements a (new?) one
without any reference or comments.
[And this is even without delving into remarks concerning the
code structure itself.]
Additionally, your patch also mixes two concepts: Adaptive
quadrature vs improper integral (which is also MATH-994); it is
hard to follow what problem this issue is supposed to point to,
and how the patch solves it. Indeed your unit tests shows a
problem with improper integrals which the class
"**IterativeGaussLegendreIntegrat**or" is _not_ meant to handle.[1]
To be clear, hopefully, you are demonstrating a problem that
occurs when combining Commons Math code with code which you
created.
The first step is to create a unit test demonstrating whether
an issue exists with "**IterativeGaussLegendreIntegrat**or" code
only (i.e. without relying on your "InfiniteIntegral" class).[1]
If no independent issue exist, then MATH-995 should be replaced
by an appropriate feature request.
Also, it would certainly be helpful to pinpoint the reason why
the combination of "**IterativeGaussLegendreIntegrat**or" and
"InfiniteIntegral" is not legitimate (if that's the case).
Regards,
Gilles
[1] Cf. also my latest comment on the MATH-995 page.
Cheers,
Ajo.
On Fri, Jun 28, 2013 at 11:07 AM, Ajo Fod <ajo....@gmail.com>
wrote:
BTW, it is possible that I'm not using LGQ correctly. If so,
please show
how to pass the tests I've added. I'd much rather use something
that is
better tested than my personal code.
-Ajo.
On Fri, Jun 28, 2013 at 11:04 AM, Ajo Fod <ajo....@gmail.com>
wrote:
I just posted a patch on this issue. Feel free to edit as
necessary to
match your standards. There is a clear issue with LGQ.
Cheers,
Ajo.
On Fri, Jun 28, 2013 at 10:54 AM, Gilles
<gil...@harfang.homelinux.org>
**wrote:
Ted,
Did you read my other (rather more lengthy) post? Is that
"jumping"?
Yes. You jumped on him rather than helped him be productive.
The
general
message is "we have something in the works, don't bother us
with your
ideas".
Then please read all the messages pertaining to those issues
more
carefully:
I never wrote such a thing (neither now nor in the past).
I pointed to a potential problem in the usage of the CM code.
I pointed (several times and in details) to problems in
candidate
contributions,
with arguments that go well beyond "bad formatting".
I pointed out how we could improve the functionality _together_
(i.e.
by
using
what we have, instead of throwing it out without even trying to
figure
out how
good or bad it is).
IMHO, these were all valid suggestions to be productive in
helping CM
to
become
better, instead of merely larger. The former indeed requires
more
effort
than
the latter.
Gilles
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
