sympy.Sum() bug when summing up reciprocal of gamma

[yz3558]

x=sympy.Symbol("x")
a=sympy.Symbol("a")
sympy.Sum(1/sympy.gamma(x),(x,0,0)).doit()
sympy.Sum(1/sympy.gamma(x),(x,0,a)).doit().subs({a:0})

These two lines give different results. The first one gives 0, while the second one gives e.
The first result is correct.

[anutosh491]

Well I can say that the result for a random integer a is correct

>>> Sum(1/gamma(x), (x, 0, a)).doit()
-E*a*lowergamma(a, 1)/gamma(a + 1) + E

[smichr]

Why does lowergamma(0,1) remain unevaluated if the evaluated form is oo? Remaining thus, 0*lowergamma(0,1) ->0 and we get the stated result, otherwise we would get nan and at least an awareness that a different strategy is necessary.

[anutosh491]

I can confirm that all cases involving positive a look fine but doesn't work otherwise . So does it mean the general sum should only be returned if a is positive (or the difference between limits is positive)

>>> Sum(1/gamma(x), (x, 0, a)).doit().subs(a, -2)
E

Yeah I would expect nan as pointed above but otherwise can't comment just by surface level analysis , cause the general sum till a random positive integer a looks fine to me !
Obviously the code snippet answering Sum(1/gamma(x), (x, 0, 0)).doit() is as follows so it returns 1/zoo

def eval_sum(f, limits):
    (i, a, b) = limits
    if a == b:
        return f.subs(i, a)

[yz3558]

Can we define 0*lowergamma(0,1)=1? This will make it consistent between a=0 and positive a values.

[anutosh491]

Can we define 0*lowergamma(0,1)=1? This will make it consistent between a=0 and positive a values.

I don't think we can do this cause lowergamma(0, 1) evaluates oo and as per sympy convention 0*oo = nan

[yz3558]

If we identify alowergamma(0,1) in the expression, instead of converting it to oo first, can we first see if we have a 0 multiplies this term? If so, we get a 1.

[anutosh491]

Why does lowergamma(0,1) remain unevaluated if the evaluated form is oo? Remaining thus, 0*lowergamma(0,1) ->0 and we get the stated result, otherwise we would get nan and at least an awareness that a different strategy is necessary.

Shouldn't it be zoo though and not oo, I was planning to make this basic change quickly but then I realized maybe we should have zoo here !

>>> lowergamma(x, y).rewrite(uppergamma)
gamma(x) - uppergamma(x, y)
>>> uppergamma(0, x).rewrite(expint)
expint(1, x)

Now expint(1, x) is finite real for all real positive x and finite imaginary for all real negative x

>>> expint(1, 3).n()
0.0130483810941970
>>> expint(1, -3).n()
-9.93383257062542 - 3.14159265358979*I

And we have gamma(0) as zoo , so returning zoo does seem more correct than oo I guess

>>> gamma(0) - uppergamma(0, 1)
Ei(-1) + zoo
>>> (gamma(0) - uppergamma(0, 1)).n()
zoo

Once I get some clarity for a preferrable ans to be returned I'll address this basic change ! @smichr

[anutosh491]

If we identify alowergamma(0,1) in the expression, instead of converting it to oo first, can we first see if we have a 0 multiplies this term? If so, we get a 1.

I don't think this would be the best way to address this . We shouldn't be writing code to address a particular case explicitly and try to build an approach which generally works fine overall !