@Alejandro Jakubi Thanks for the debug info. It's nice that there is a way for Maple to display what's it doing internally. I now seem to recall using something like that many years ago in an older Maple.

I also noted the usage of Ei(a,z) in the solution when I tried approaching it by getting the primitive evaluated at -L and L, with L > 0, then taking a limit L = infinity. A sum of Ei() funcitons is quite obvious as it's pretty much a direct decomposition of h(), but it seems it doesn't play nice with parameters in Maple (or more complex scenarios).

Is it worth reporting this (apparent) bug to Maple?

Alex.

p.s. This is off-topic: can you constrain Maple to avoid or include certain functions/procedures when it integrates?

@Markiyan Hirnyk Could be. Though note that the integral I posted is on -infinity..infinity (not 0..infinity).

It is 0 for (m,n,p,q)=(2,-1,-3,-6) but other (m,n,p,q) yield non-zero values, even when (m,n,p,q) is only partly specified. For instance:

int(h(x, 2, -1, -3, -6), x = -infinity .. infinity)

yields 0 ... which is correct (numeric intergration gives 2.3e-11 - I*1.6e-6 ... close enough).

int(h(x, 2, n, 2, n), x = -infinity .. infinity)

yields -I/4/Pi ... which is correct (n not-specified, can be anything).

int(h(x, m, n, m, n), x = -infinity .. infinity)

yields -I*m/2/Pi ... which is correct (m=p and n=q not specified, can be anything).

int(h(x, m, n, p, q), x = -infinity .. infinity)

yields 0 ... which is wrong ... should depend on (m,n,p,q).

Something is fishy and I'm not an expert enough in Maple to figure out why or how to fix it.

@Markiyan Hirnyk you seem offended and I have no idea why that is, as I had no such intentions. I do appreciate your time and efforts.

I did not say I dislike your outputs. I said that they simplify to 0, which you can verify or you can look at the file I attached. This was the original problem, 0 is the wrong result.

Also, h(x) actually does not have any singularities. The value/limit at x=m and x=p is finite. I can write h(x) as a product of the form A*exp(Bx)*sinc(Cx)*sinc(D(x-m))*sinc(E(x-p)) which is finite for all x, including x=p and x=m. I don't want to get into an argument, but as far as I know, the exponential integral, i.e. int(exp(-jz)/z^a) is a CPV integral when a=1 and z<0 (which can be extended to all reals or complexes), h() can be decomposed via partial fractions into a sum of functions of the form exp(-jz)/z ... by "of the form" I mean you can replace z with z-A where A is some constant. I didn't find this decomposition to be a helpful approach though (yet).

Alex.

@Markiyan Hirnyk You are right about the CPV integral. h() can be decomposed via partial fractions into a sum of 1-argument exponential integrals of the form int(e(-jz)/z), which is indeed a CPV integral. It seems that this is what Maple is trying to do ...

Edit: Actually, if you work it out, everything simplifies away and you get 0 in both cases, so the problem is still there ... you can also verify this by doing factor(expand(int(Re(h),...,CPV))). See attached file which is using your code:

CPV-0.mw

Is there a better way to express the parametric function h() to make it easier for Maple integration?

Alex.

p.s. Computing the integral of the real/imaginary part works even without using the CPV option. Probably Maple identifies the CPV integral and doe sit intrinsically. It took almost 4 minutes to do int(Re(h())) and int(Im(h())), and I have a 5 GHz quad core machine ... interesting. Adding the CPV option didn't affect speed.

@Alejandro Jakubi Thanks for that. I was yesterday looking at going via the Fourier transform + Parseval's + convolution in order to solve it on paper ... skimming through the thread you linked to, it seems they reached a similar solution to their problem,

My problem however still remains, i.e. Maple giving multiple correct results (which suggests a bug) and being unable to get an analytic expression from it. The function h() in my case is a particular case of a function series involving 2 sinc() multiplied with something else (in this case a 3rd sinc(), but not always) ... Maple the same issue even with just 2 sincs(). I wouldn't want to use paper for each and like to be able to rely on Maple.

I'll see if I can automate the FT + Parseval approach for my function series.

I'd still apreciate a fix for the initial unexpected behaviour ... could it be a bug, you reckon?

Alex

@nm I was mostly pointing out that the 0 result is verifiably wrong and was asking whether anyone knows how/if I can get Maple to yield a correct analytic expression that depends on (m,n,p,q).

The function h() can be decomposed into a product of 3 sinc() functions (i.e. the sin(x)/x) kind), whose integral is finite. The division by 0 shoud normally not be an issue (the limit at that point is finite).

I tried using -L..L instead of -infinity..infinity and then do a limit (on paper or also Maple) but the expression you get then is 2 pages long, although some simplifies away.

Any clues?

p.s. Yes, I';m sure that -I/2/Pi is correct. You can also check it numerically (note the big "i" in "Int"):

evalf(Int(h(x, 1, 1, 1, 1), x = -infinity .. infinity))

yields -6.601e-13 - I*0.1591549431, which is basically -I/2/Pi