Fix Python int problem with exp_integral

[kcrisman]

In #11143 we weren't careful about Python ints. There are lots of examples of this, so one will want to go through the whole file.

sage: exp_integral_e(int(3),0)
0
sage: exp_integral_e(3,0)
1/2

Depends on #17130

CC: @benjaminfjones @burcin @eviatarbach

Component: symbolics

Author: Jeroen Demeyer

Branch/Commit: 68c545a

Reviewer: Ralf Stephan

Issue created by migration from https://trac.sagemath.org/ticket/14766

[eviatarbach]

comment:3

I'm guessing this occurs in other files too.

I think it's unreasonable to expect everyone adding symbolic functions to worry about this, and certainly users to be aware of it; maybe we could make BuiltinFunction.__call__ automatically convert int to Integer? Or have it raise an error if an int is in the parameters? Allowing int into _eval_ causes other problems too, such as getting expressions with int pyobjects in them, making arithmetic slower, etc.

At the very least, we could temporarily add from future import division in all files that implement symbolic functions; then exact answers wouldn't be returned in all cases where they should, but at least mathematically wrong answers wouldn't occur.

[benjaminfjones]

comment:4

I think my preference would be either raising a TypeError (and clearly documenting what the allowed types are) or doing Python 3 style division. I don't like the idea of adding an implicit coercion int -> Integer.

If we do type checking in BuiltinFunction.__call__, we should make sure that there isn't a significant performance penalty.