Question: Numeric Integration

I ran into an interesting situation with numeric integration.

For a simulation task I need to evaluate an overlap integral of a pair of 3-d ellipsoids which have a certain aspect ratio and the axes of which are tilted against each other. The distribution in each plane is Gaussian, but with largely differing sizes. While I have an analytic expression for the result; the integration (along a certain direction) cannot be done analytically and so I integrate numerically. In principle, the integration goes from -infinity..infinity although in practice one can define a suitably large fixed interval to get a solution with good accuracy.

Maple has two numeric routines that do infinite intervals: _Sinc and _d01amc. For reasons I haven't found out yet _d01amc gives the wrong result for me (by many orders of magnitude) so I have been using _Sinc. Its results make sense.

The integration runs inside a loop with many (hunderd or thousands) of iterations. Trying to understand the time the code takes I discovered that the time depends quadratically on the number of iterations. I have condensed the problem into a test case uploaded below and find the same behaviour. In the test case; an inner loop integrates 40 cases (cycles) and an outer loop runs the inner loop 50 times (periods). I time each execution of the inner loop to produce the timing plots. One parameter gets varied randomly to prevent Maple from outsmarting me and optimizing the integrations away.

 

Here is the timing result (time taken for each period [=40 integrations] vs period number):



The salient point: The time taken per period increases.

For comparison; I ran the same problem with a fixed interval using _d01akc. Here is that result:

I cannot explain the outliers but they are always there. The salient point is: the time/period is constant.

 

While I can understand the comparatively long time _Sinc takes, I cannot understand why it gets slower with the number of iterations. There may be a memory leak; that is harder to detect. But, technically, each integration is completely independent of the previous or next one and should take roughly the same amount of time.

 

With numerical integration it is often "caveat integrator", but the quadratic dependence of time taken by _Sinc is hard to understand. Most importantly; it makes the code impossibly slow as I am running against the wall with the number of iterations. n^2 is not acceptable scaling.

 

Or am I doing something wrong here?? I am posting the .mw file in case someone is interested enough to check on this. Also, all timings were dong on Maple 15 on a G4 PowerBook (1.67 GHz). At some time I'll try Maple 17 but haven't gotten to that yet (needs a different computer).

NumIntExample.mw

I was tempting to post rather than pose this question as I have a work-around and as I do not see a clear fundamental solution. If enough people agree that this is a bug then I'll file an SCR after I verified it is still present in Maple 17. In fact, if a bug I even want this fixed in Maple 15 as I cannot run newer ones on this G4.

Thanks in advance for any comments.

Mac Dude.

Edit: I now ran the same sheet in Maple 17/Snow Leopard. While the times are shorter by a factor 4 or so (reflecting the faster CPU) I still get the increase in time/period for _Sinc whereas d01akc remains at constant execution time. So whatever causes the problem with _Sinc it is not fixed in Maple 17.00.

My apologies, the figures don't show. Maybe someone can explain how to upload images, The first one shows an upward slope; the 2nd one a constant number with some noise and two spikes (outliers). I don't know how to upload & make them show. Please look at the .mw file for more details.

Please Wait...