>> Also, note that @chainable does some magic :) Every operation returns >> a new proxy, so I can store whatever I need. Currently I only store >> the "state" (via closure) and a parent reference, but rather than >> building state, I could just store (operation, [arguments]). There >> are a few downsides to that from my perspective: >> >> 1.) All arguments are evaluated immediately >> 2.) You lose the nice ability to "swap" variables in the closure. >> 3.) You are going to have to generate the "compiled" python expression >> eventually anyhow >> >> The main advantage of the (function, [arguments]) tuple is that it >> lets you defer "compiling" the expression into python, so if you want >> to go back and replace all __add__ calls with __wackyadd__ later on, >> you can do that easily. You could achieve the same behavior with the >> benefits of closures by having a "func" variable in the closure that >> points to the unbound type.__method__, then using that in the returned >> function. The (function, [arguments]) version is also easier to >> introspect, however there is nothing to stop you from decorating the >> proxy object with the same info. > > Another advantage of doing it the other way: you can change the > precedence order of operators. This would be kind of magical (read: > hackish) if done at this level, but it should be doable.
I don't quite understand what you mean. When you say "change the precedence order of operators" are you referring to rewriting the expression after it has been built? >>> But the point is that automatic simplification cannot be overridden, >>> at least in the same context, so it should only be done if you are >>> certain that no one would ever not want it done (in that context). >> >> I think "no one would ever not want it done" is a pretty good criteria. > > Right. You have to consider context too. Some people do want to write > x + x without it turning into 2*x. In SymPy, they can do this with > Add(x, x, evaluate=False). This might be considered a different > "context". Certainly expressions created this way won't work in some > algorithms without being evaluated first. > > But calling the objects with evaluate=False is messy and hard to > write. My hope is that this discussion will lead to something easier > to use, and possibly more powerful. If you start from a very general symbolic expression that is pretty much "as written", I think automatically performing whatever evaluation is required for the function not to raise an exception would be reasonable. You could decorate the expressions with the your evaluated isomorphism. Of course, then you'd have to track mutations to the expression and throw away any isomorphisms that were on ancestors of mutated nodes. If someone explicitly simplifies the expression you could just swap nodes with any already calculated canonical isomorphisms. > And I agree about bool, or at least booleans. One thing that came up > recently was that someone wanted to be able to write x < y < z and > create a symbolic object out of it. This is impossible, because this > evaluates to x < y and y < z, and there is no way to override the > logic operators or their short circuits. > > Using PyPy to get things working that are "broken" in Python is an > interesting idea. I noticed that PyPy doesn't have the stupid > restriction that __contains__ return a bool that CPython does, so we > could actually implement an In() object there. PyPy is an awesome sandbox :) The python/rpython separation and application/iterpreter level objects takes some getting used to, but things by and large are VERY accessible. In particular, object spaces expose most stuff you'd want to change. The behavior of and/or/not/is are exceptions (those are buried in the interpreter). Getting even trivial stuff changed in the CPython interpreter is a rough process, but a working implementation and concrete use case does a lot to advance your position. Nathan -- 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.
