commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gilles <gil...@harfang.homelinux.org>
Subject Re: [math] On MATH-995: Problems with LegendreGaussQuadrature class.
Date Mon, 01 Jul 2013 15:22:15 GMT
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
"IterativeGaussLegendreIntegrator" 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 "IterativeGaussLegendreIntegrator" 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 "IterativeGaussLegendreIntegrator" 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.fod@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.fod@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 
>>> <gilles@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
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message