Le vendredi 09 mars 2012 à 00:05 +0100, krastanov.ste...@gmail.com a écrit : > As it stands now, for building symbolic systems different from simple > combinations of functions of and operators on mostly commutative > symbols, one needs to subclass Expr and/or add more stuff to Mul, Add, > etc. > > Examples: MatrixSymbol and Quantum subclass Expr. Units adds stuff to > Mul and Add. > > It seems that this is not sustainable because > 1. Adding too much stuff to Mul and Add > https://code.google.com/p/sympy/issues/detail?id=1941 > 2. Mixing subclasses of Expr can give strange results.
+1 > A solution that I like is working on AST trees. See > https://groups.google.com/d/msg/sympy/fCQEdSQybTM/X04kBhbIEGUJ How is that different from the existing expression trees? If you really have *syntax* trees in mind, then it's not a suitable solution since you can't take advantage of the commutativity of addition or of the associativity of multiplication (syntactically, "a + b" and "b + a" are different things). > It is possible that I will need much of this functionality if I > proceed to apply for GSoC with a multi-linear algebra / differential > geometry project. > > A first step (that I have requested a few months ago, when I was > working on lambdify) will be to at least have a nice api for > traversing all args. I have asked for that here > https://groups.google.com/d/topic/sympy/Pa3k3WETPC0/discussion > > So I plan to add methods that take evaluate=False expressions and > generate the syntax tree (in the form of tuples at first, something > more pythonic later). And also add other methods that work with those > syntax trees (validation, canonicalization). > > In one sentence, at the moment Add and Mul and others are both > containers and canonicalizators (if this word exists :). I want to > have them separate, so different canonicalizators can be used on the > same expr (real algebra vs quantum module vs multilinear vs group > theory vs any other system that works on symbols). I'm not sure what you mean by canonicaliser, but I'll assume you refer to Add(*foo) being used to compute the sum of the elements of foo. I agree that it's a problem and a violation of the single-responsibility principle. We should replace Add(*foo) with an efficient function ssum(foo). > This means that at least at the beginning Add, Mul, etc will be used > as they are now - both containers and canonicalizators for the real > algebra that sympy supports, but at the same time they will be used > with evaluate=False as only containers for other symbolic systems. evaluate=False isn't usable for what you want to do as it destroys any attempt at establishing useful invariants for your objects (such as expr.__class__(*expr.args) == expr). > > @Nathan Rice, If I understand correctly, your idea is to have the > entire core of sympy working in that manner. Am I correct? Do you have > some proof of concept code? > > @community, Is this an acceptable solution for the possible future > work on Expr and in my case on multi-linear algebra? > > @Aaron and community, has this been discussed before? Was there > something about different base algebra systems? > > Stefan > -- 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.
