On May 6, 2011, at 6:09 PM, Alexey U. Gudchenko wrote: > 02.05.2011 20:25, Ronan Lamy пишет: >> Le dimanche 01 mai 2011 à 23:37 -0700, Ondrej Certik a écrit : > >>> >>> You should assume it. Non commutative symbols are just making things >>> very complicated, and it was a mistake to add them into the core of >>> sympy. They should start in sympy.quantum, and only after they are >>> being used a lot, we should start thinking how to handle them >>> properly. >> >> I agree on this. Non-commutative Symbols don't make a lot of sense. If >> we didn't have them (and severed the inheritance from Boolean), we could >> say that Symbols are complex variables. Instead, we have a murky >> definition. >> Anyway, is_commutative is just an extreme example. Most .__new__() >> and .eval() methods check one assumption or other. We'd have to throw >> all that code away and rewrite it from scratch. >> > > > Non-commutative Symbols are generalization, commutative Symbols are > specialization. (Remarking that it is a pure mathematica, not a quantum - > because there are no physical lows used when we consider Non-commutative > Symbols), > but I agree that temporary it can be placed in sympy.quantum for tactic aims. > > In any case it would be convinient (and for effective core - to avoid > unnesesary checking) to isolate in the core the possibility to work with > commutative Symbols and possibility to work with non-commutative Symbols (or > even with non-associative symbols). Now, as I understand, in the SymPy core > the non-commutative core is not isolated, and at the same time by defult the > is_commutative is switch off (False) - but many unnecessary checking are used > further and we continue to deal with commutative.
Basically, the Mul (in Mul.flatten()) keeps track of a commutative and non-commutative part of an expression. The problem with keeping it in the core is that every function has to properly handle non-commutatives. There are quite a few cases where functions make the assumption that the expression is entirely commutative and return wrong results as a result. This also goes back to the extensibility/editability of the core. If you want to modify the core, and do it correctly, you need to make sure non-commutative expressions are handled correctly. Aaron Meurer > > So the isolation is needed in any case (effective core) - even after "we > should start thinking how to handle them properly". > > May be the interface of objects can be used for this. > > This type of assumption is classified as related with algebraic fields/rings. > (For this type of assumptions may be meaningless to attach assumption to > symbols at whole ) > > -- > Alexey U. -- 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.
