This is from comment: https://sourceforge.net/p/maxima/mailman/message/51782153/
One can check this against other CAS systems with sage:
sage: integrate(sin(x)/x, x,-M,M,algorithm='maxima').limit(M=infinity)
0
sage: integrate(sin(x)/x, x,-M,M,algorithm='giac').limit(M=infinity)
pi
sage: integrate(sin(x)/x, x,-M,M,algorithm='fricas').limit(M=infinity)
pi
For the record, the equivalent Maxima-specific formulation is
Not clear to me where the error is entering the picture, whether
integrate
is calling the limit code and the error is inlimit
, or ifintegrate
is getting mixed up on its own.integrate
has trouble with related problems if 0 is in the interval of integration, but it seems to be okay if 0 is excluded, e.g.seems okay (it's approximately pi/2) but
provokes "unfamiliar singularity".
Incidentally:
OK:
OK:
Not OK:
A better antiderivative for
integrate(sin(x)/x,x,-M,M)
isexpintegral_si(M) - expintegral_si(-M)
. AndI think that antiderivative is better than the one we return today which involves
gamma_incomplete(0,%i*x)
. The occurrence of%i
is kind of messy looking.Yes, it's messy, but it is also discontinuous at zero. And that gives rise to the bug.
I think that the source of this less than ideal antiderivative is the case
M2-EXP-TYPE-2
in the functionintegrate-exp-special
(defined in sin.lisp). Actually, the integrand has been exponentialized before arriving atintegrate-exp-special
, so maybe this needs to be patched before enteringintegrate-exp-special
?