Int(exp(-1/100+1/1000*I*u)/(4*u^2+1)*exp(1/2*I*u),u = 0 .. 1)
The integrand has positive real and imaginary parts over the
range (just use plot it) and numerical evaluation gives it as
0.53434219089626 + 0.98249392969436e-1 * I (using Digits:=14).
A symbolic integration and using evalf gives the same.
Now writes this as
tstData:=[a=0, b=1, m=1/2, b0 = -1/100, b1 = 1/1000];
J:=Int(exp(b0+b1*u*I)/(4*u^2+1)*exp(u*m*I),u = a .. b);
0.53434219089626 + 0.098249392969436 I
However interchanging evaluations results in a false answer:
E:=value(J); # the general result for the integral
eval(E,tstData); # apply the test data
-0.67621737672440 + 0.098249392969425 I
I think it has to do with the way, how Maple handles branching.
Additionally it behaves quite odd if one either plots E or
whether one evaluates it:
basicE:=eval(%,tstData); # antiderivative feed with data
plot( [Re(%),Im(%)], u=-0.1 .. 1, color=[red,blue]);
For the real part that plot shows a jump in 0 and that it is
*negative* (and increasing) over the integration range, so the
above numerics fits into that:
the fundamental theorem gives it as value in 1 - value in 0
= -.7093759291406e-1 - (-.60527978381032) = .53434219089626
if folloing the graphics.
However evaluating gives something different and that may
cause the above seen error:
eval(basicE, u=0): evalf(%);
0.60527978381032 - 0.22752165689331 I
So it says the real part is *positive* in u=0.
Probably one can simplify the above to the case Ei(1, -1)
or so (but have no patientents for that anymore, already the
above needed hours to locate it in a larger setting ...).
After a longer fight (passing to Si and Ci as my parameters
are real) I think that the correct rule involving branching
BTW: I was a bit astonished that Maple cannot simplify away the
multiplicative constants in 'csgn'.
I also went the way through the 'entire' exponential integral
function 'Ein' (I think it tributed to Tricomi) in series form,
that is Ei(1,z) = Sum - ln - gamma (c.f. help + Advisor), but
the branching problem seems to be the same (so may be one can
do similar with ln instead of Ei, as the analytic Sum can not
contribute to the troubles here - I evaluated it numerically).
Any idea or pointing to possible (handling) errors are welcome.