Does order of multiplication really matter when using simplify ?

I noticed, when I type the following commands:

 syms x; 
 syms n integer; 
 cn = int(abs(x)*exp(-i*n*x),x,-pi,pi); 
 cnp = 1/(2*pi)*cn; %Order of mult. 
 display(simplify(cnp))

ans = 

the value of cnp is widely expanded (even using format short)

However by a smal change:

  cnp = cn*1/(2*pi); %Order of mult. 

that expansion is eradicated, as one can observe:

   display(simplify(cnp))

ans = 

Why is that?

Answer 1

[Paul]

I suspect that in the first instance the term 1/(2*pi) is first evaluated numerically, and then the result in coverted to symbolic for multiplication with cn, which is a sym object. In the second case it seems that the rules of precedence would would say that 2*pi would be evaluated first, and when that's converted to to a sym it's recognized as 2*pi. In any case, probably best to always use sym(pi)

syms x
syms n integer
cn = int(abs(x)*exp(-1i*n*x),x,-pi,pi);
cnp = 1/(2*sym(pi))*cn

cnp = 

cnp = cn*1/(2*sym(pi))

cnp = 

Answer 2

[Walter Roberson]

The Symbolic toolbox has algorithms for trying to get a "nice" representation for any given floating point number. Those algorithms can generally notice rational multiples of pi with up to denominator 9999 . However, the algorithms are not designed to be able to detect division by pi.

In the 1/(2*pi) case, the calculation has already been done in floating point, and the symbolic engine does not happen to notice that the result can be represented "nicely"

In the case where the symbolic expression is first, multiplied by 1/(2*pi), the symbolic expression is first multiplied by 1, which gives the symbolic expression. Then the bracketed (2*pi) is evaluated in floating point. Then it has to convert that floating point number to symbolic, and this time it is a simple rational multiple of pi so it is able to detect that and substitute 2*(symbolic pi) . Then the division of the symbolic expression by symbolic 2*symbolic pi gets displayed nicely.

When you mix floating point with symbolic, it is best to explicitly convert the floating point to symbolic early, to prevent possibilities such as this .