I don't remember if Mul args appear in the same order that they are
printed, but it doesn't really matter. In this case, there is more
than one valid answer, so it's correct for the algorithm to pick
either of them arbitrarily (similar to how (x*y).match(a*b) for plain
Wild('a') and Wild('b') with no excludes could be any of {a: x, b:y},
{a:y, b:x}, {a:1, b:x*y}, or {a:x*y, b:1}). Going from left to right
certainly sounds like a consistant way to keep things simple within
the algorithm.
Aaron Meurer
On Mon, Aug 15, 2011 at 12:12 AM, smichr <[email protected]> wrote:
> When there is a conflict between two "attractors" I am giving the one
> that appears earlier in the expression the precedence. This gives a
> logical 'left to right' processing behavior where the first root from
> left to right gets first option of joining with preceding bases. Does
> this look right or should the xy have gotten the update instead of cx:
>
> >>> x*y*sqrt(x*y)*sqrt(x*c)*c
> c*x*y*(c*x)**(1/2)*(x*y)**(1/2)
> >>> powsimp(_)
> y*(c*x)**(3/2)*(x*y)**(1/2)
>
> --
> You received this message because you are subscribed to the Google Groups
> "sympy" 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?hl=en.
>
>
--
You received this message because you are subscribed to the Google Groups
"sympy" 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?hl=en.
