One issue with this is that we often associate the idea of commutativity to Symbols instead of operations. In particular I think that physics uses non-commutative symbols in Muls a lot. So some Muls are commutative and some are not.
On Wed, Oct 31, 2012 at 8:26 AM, Sergiu Ivanov <[email protected]>wrote: > Hello, > > On Wed, Oct 31, 2012 at 08:07:26AM -0500, Matthew Rocklin wrote: > > > > Unfortunately, when I go to check if expr is commutative > > > > >>> expr.is_commutative > > AttributeError ... > > > > I get an AttributeError. This is because is_commutative is glommed onto > the > > object in the constructor rather than being a class variable or a > > function/property. I've noticed in the code that is_commutative has been > > special cased for performance reasons. > > > > What is the best way around this? > > While thinking over is_commutative and is_associative, it has occurred > to me that we should maybe try to derive something like CommutativeOp > from Basic to mimic AssocOp. This should sort out your problem, but > I'm not sure as to how much effort this may require. > > Sergiu > > -- > 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.
