Changing order of factors affects sympy expansion

there is a strange behaviour when using sympy inside sage:

from sympy import Symbol, exp, I
import sympy
x = Symbol("x", real=True)

then, asking for exp(I*8*x).expand(complex=True) I get

I*sin(8*x) + cos(8*x)

that's ok. however, asking for exp(8*I*x).expand(complex=True), I get

I*exp(-8*im(x))*sin(8*re(x)) + exp(-8*im(x))*cos(8*re(x))

Why in the second case it forgets that $x$ is real? Is this behaviour expected?

this was causing me real trouble in another context, since I was calling functions from a package that itself uses sympy, and they didn't work unless some special ordering of the arguments was given.

I'm on SMC with sagemath kernel 6.10. I've checked in Live SymPy, the 1st result is obtained in both cases.

edit retag close merge delete

(1*I).parent() gives SR, while (I*1).parent() gives 'ImaginaryUnit' object has no attribute 'parent'. My guess is that given a product it is searching for the parent of each operand sequentially, and it fails since I has no parent. Is this kind of shortcut useful in another context?

Sort by » oldest newest most voted

The main issue seems indeed that coercion is not well defined with sympy objects. Symbolics is handled by Sage with giacpy, and not sympy, this latter is not even imported at startup, which might explain the lack of integration of sympy within Sage. There have been some discussions to make sympy (or even csympy) the handler of symbolics in Sage, but it is not the case.

The coercion enters the game because 8 is a Sage integer, not a Python int. If you want to avoid that you can turn off preparsing, by doing:

sage: preparser(False)

Alternatively, you can tell Sage that 8 is a python int, in one of the following ways:

sage: 8r*I*x
8*I*x
sage: int(8)*I*x
8*I*x
more