Comment #3 on issue 3169 by [email protected]: qapply fully expands arguments
http://code.google.com/p/sympy/issues/detail?id=3169
So when I first saw this, I was only thinking of the relatively simple case Matthew noted above, where you end up with some scalars multiplying a state, which would be easy to treat with args_cnc. Specifically, I was thinking of J2*JzKet(j,m), which gives hbar**2*j*(j+1)*JzKet(j,m) and is expanded to hbar**2*j**2*JzKet(j,m)+hbar**2*j*JzKet(j,m). However, there are definitely more subtle cases this would have to address.
Most of the subtlety comes in expanding sums when the args aren't all commutative and collecting sums at the end which may come from different state/operator pairs. I'll lean heavily on the angular momentum stuff as examples, but if this were to be implemented, it would need to produce the following: - (x+Operator())*Ket() where Ket diagonalizes Operator, e.g. (x+Jz)*JzKet(j,m) == (x+hbar*m)*JzKet(j,m) - (x+Operator())*Ket() where Ket does not diagonalize Operator, e.g. (x+Jx)*JzKet(1,1) == x*JzKet(1,1)+hbar*sqrt(2)*JzKet(1,0)/2 - Different operator/state pairs giving the same state after applying, e.g. Jplus*JzKet(j,m-1)+Jminus*JzKet(j,m+1) == hbar*(sqrt(j**2+j-m**2-m)+sqrt(j**2+j-m**2+m))*JzKet(j,m) Especially with cases like this last one, I'm not sure how this could be detected while things are being applied, it would have to be factored out somehow at the end.
Given this, I think doing an .args_cnc in qapply before calling qapply_Mul would be okay and would handle the trivial case of not expanding commutative expressions, but more would have to go in to call this issue closed.
-- You received this message because you are subscribed to the Google Groups "sympy-issues" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/sympy-issues?hl=en.
