On Thu, Mar 8, 2012 at 4:05 PM, krastanov.ste...@gmail.com <krastanov.ste...@gmail.com> wrote: > 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. > > A solution that I like is working on AST trees. See > https://groups.google.com/d/msg/sympy/fCQEdSQybTM/X04kBhbIEGUJ > > 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).
This is definitely a huge problem, if not just for the unmaintatinability of the code. I wanted to change S.NegativeInfinity to be implemented as just Mul(-1, S.Infinity) (http://code.google.com/p/sympy/issues/detail?id=3059), but the logic in Mul.flatten was so complicated that I've yet to muster up the time to really go through it and make sure everything is right. > > 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. So you want to separate the canonicalizers from both the objects and the containers? It seems to me that it would be best to just put them in the objects themselves, probably just using the Python double dispatch system, but this is an interesting idea too. Would that make it more or less extensible? Let's start a wiki page with these ideas. For starters, I think we should list every kind of object that would want to have it's own "canconicalizer", including at least half a dozen that are currently special cased in the core (Mul.flatten mostly). Then we will get an idea of what kind of functionality we need, and how we can go about implementing it. > > @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? Not that I know of (or can currently think of anyway), but there could have been stuff from way before I joined the project, especially relating to sympy-core. I guess there was the whole discussion with _op_priority and so on last year. Was that before you started following things? Aaron Meurer > > 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. > -- 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.
