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 so my guess would be that you can replace the following line in AdaptiveQuadrature.proc():
double Q1 = delta / 6 * (va + 4 * vm + vb); with a modification adapted from IterativeLegendreGaussIntegrator.stage(n) line for integration as follows: Q1 = delta * FACTORY.legendreHighPrecision(numberOfPoints, a, b).integrate(fn); Q2 = delta * FACTORY.legendreHighPrecision(numberOfPoints+1, a, b).integrate(fn); ... or some slight modification of the above. 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? If it is indeed supposed to do the integration, then AQ clearly does a better job. 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. Summary: I'm demonstrating a clear bug/inefficiency with LGQ and providing you with an alternative that is more accurate. Cheers, Ajo. 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-unsubscribe@commons.**apache.org<dev-unsubscr...@commons.apache.org> > For additional commands, e-mail: dev-h...@commons.apache.org > >
