Hi.
Thanks for pointing out the inefficiency in AQ. I just improved the
efficiency of AQ to 1.41x that of LGQ (up from 1.05x) - measured in
digits
of accuracy per evaluation for integral of normal with sigma 1000 in
range
[-5000, 5000]
Efficiency improvement is another type of enhancement request; again we
need numbers to back it up. [There is a benchmarking utility in the
"test"
part of the code repository (class "PerfTestUtils").]
Please let me know if this doesn't answer your question about the
discussion:
In essence Gilles thinks there is no problem with LGQ because it
integrates
the low frequency functions in his unit tests accurately.
I didn't say that the Gauss-Legendre quadrature scheme is the answer to
any integration need (otherwise no other scheme would need to exist),
nor
did I say that the "IterativeGaussLegendreIntegrator" is adequate in
every
circumstance.
Quite the contrary, with the change of variables under consideration,
they
are not adequate. This is not necessarily a bug.
He thinks that
the problem is with the function I provided because it has "numerical
instabilities" while I think it is the high frequency nature of the
function that LGQ can't handle because it divides intervals
indiscriminately.
Yes. But that's not a bug; it's a limitation.
You are most welcome to document it in the userguide.
So, it is not clear to me how Gilles explains why AQ
converges to the right answer in the presence of these "numerical
instabilities" ... after all, LGQ and AQ are being passed the same
function
and identical limits.
Because the _limitation_ of "IterativeGaussLegendreIntegrator" is that
it does not analyze where the error comes from; it just keeps on
dividing
the whole range, piling up numerical errors in the region where few
points
are needed (and where the contribution to the integral is ever more
insignificant the larger sigma becomes).
Thus: it is wrong to use this algorithm in this case (i.e. when the
significant contributions to the integral happen to lie outside the
range
sampled by the Gauss-Legendre quadrature scheme); could you agree that
this is not the same thing as considering that the algorithm is buggy?
This problem should appear with any function that has sufficiently
high
frequency components. It would be better if LGQ threw an exception
when it
encounters a high frequency function.
This is not part of the algorithm. It's a possible enhancement.
You are welcome to provide a tool that performs the analysis.
Instead, it "converges" confidently
to the wrong answer.
No. The user attempted to use a tool that is not adapted to the
situation; I think that we showed that this change of variables
does not get along with "IterativeGaussLegendreIntegrator".
You are welcome to clarify the documentation of this algorithm.
I personally think that AQ will fail at some point at
a high enough frequency ... but that will be well beyond the point at
which
LGQ fails.
I've avoided the complex method of fetching weights used in the
current
schemes because the improvement in efficiency arises from the
adaptive
nature of the AQ method. You may notice that I'm using the weights
that you
use in your code. I think Gilles requires that I use the weight
generation
scheme he has worked with in the codebase in order to consider the
code
usable in Apache MATH.
In summary, I feel the accuracy and versatility of AQ are being
ignored in
favor of the familiarity of LGQ in the apache codebase.
The shortcomings of "IterativeGaussLegendreIntegrator" are not being
"ignored" but we usually try to think about how to best implement
improvements and new features. Crucial considerations involve code
reuse
and maintainability. Another driver is: realistic use-cases.
If there are tests
that AQ fails, I'll update my opinion.
You are getting it the other way around. [See previous posts on how to
report
bugs and provide new features.] You could also have a look at this
issue
https://issues.apache.org/jira/browse/MATH-816
for a practical and successful application of the principles which I
tried to
pass on during this discussion.
Regards,
Gilles
[...]
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
