13.05.2011 23:33, Alexey U. Gudchenko пишет:
07.05.2011 22:27, Aaron S. Meurer пишет:
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
Yes the extensibility/editability of the code is importent (really the
isolation is needed for it).
I think that, first of all, we should to analize and separate the code
wich consern to the commutatives (or non commutatives) in the separated
methods. Then we can define appropriated classes (name spaces) which in
isolated mode (without unnecessary checking) respond to the realization.
--- SymbolBase
--- SymbolComExt (only commutative code, checking and so on)
--- SymbolNonComExt (only non commutative code, checking and so on)
when we want to use some kind of symbols then we can use class's fabric
in the Symbol('x', commutative=True) procedure which yield apropriated
class or its successor.
By "class's fabric" I meant "Class Factory".
Alexey U.
--
Alexey U.
--
You received this message because you are subscribed to the Google Groups
"sympy" group.
To post to this group, send email to sympy@googlegroups.com.
To unsubscribe from this group, send email to
sympy+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/sympy?hl=en.
