On Mon, Feb 13, 2012 at 7:33 AM, Nathan Rice <nathan.alexander.r...@gmail.com> wrote: > On Sun, Feb 12, 2012 at 7:31 AM, Andy Ray Terrel <andy.ter...@gmail.com> > wrote: >> FWIW, Andreas Kloeckner's Pymbolic code is closer to what Nathan is >> suggesting. He builds trees and then operates on them with visitors. >> Its a nice system but not nearly feature complete. SymPy relies on >> quite a bit on "construction time" logic to reduce things to canonical >> form. Pymbolic relies on visitors to rewrite the graph. This makes >> Pymbolic faster for building simple exprs but leaves error checking >> until the end of the computation. It also has the nice affect of >> being very extensible. >> >> While I agree it would be nice to have a more general AST that can go >> between these projects, I don't know that it is feasible to switch >> SymPy. It would be much more work. > > I was thinking about the easiest way to integrate an AST/visitor style > into SymPy. Rather than move everything to use the AST style > construct, I think it would be easier to have a function that converts > from one form to another. Since I construct a graph that encodes the > order in which the operations occurred, you could just walk from the > starting points, converting in order. > > The main difficulty with the AST is that things which are expressions > in python are statements in the AST, and behave differently. The > biggest offender here are the in place operations. I have to think of > a nice interface to encode multiple symbol parents to a given state as > well, I'm not happy with anything I've tried so far. If you guys have > any suggestions as far as how you would like to access all the symbols > in an expression I would love to hear your thoughts. > > Nathan >
At present our core is immutable, so we haven't really dealt with those problems very much. But we would like to experiment with a mutable core at some point, so solving these problems would be useful. So you want to allow nested in-place operators? In other words, something like x*(x += 1) would be allowed (e.g., if x starts as 2, this would give 3). This presents some interesting possibilities, but also some difficulties. One thing that might be a limitation is that Python doesn't make the distinction between += and =+ like languages that allow this do (like C). Consider this. If you have something like x*(y*z), this is computed as x.__mul__(y.__mul__(z)) (ignore the existence of __rmul__ for now). This can be computed in that order, i.e., first compute x, then recursively compute y.__mul__(z), and pass that to x.__mul__(). In AST, this means that you convert it to preorder traversal. But preorder traversal is equivalent to using a stack with infix. What happens then when using a stack doesn't work? What if you have x*((x += 1)*y)? If you first compute x, then try to recursively compute (x += 1)*y, this will be wrong, because x += 1 will change the value of the x you already computed. How do languages like C that support these things implement them (or more specifically, how do the compilers implement them)? I suppose you have to do some kind of ordered topological sort on the tree, or something like that, but I'm just guessing. Aaron Meurer -- 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.
