I am the author of elementwise (http://packages.python.org/ elementwise/) and constraints (http://packages.python.org/ constraintslib/). These tools are similar to SymPy in their use of symbolic proxy objects to represent values that may be provided later (and to some degree in their target audience).
I'm getting in touch because: 1.) I'd like to get people on board with the idea of a standard symbol proxy. The general case is basically doing anything with a symbol returns another symbol representing the resulting expression. While you do this to some degree now, the way in which you've gone about it only allows you to use functions that return a wrapper object (Add, Pow, etc). Anyone that wants to interact SymPy has to take and return these objects. A much better scenario is to have and symbolic expressions that can be realized down to normal python code (and which can be generated in a general manner from ASTs). This gives you full interoperability with regular Python code. 2.) I noticed that a type system was on your roadmap. Given a solution can be achieved for #1, I feel this has broad applicability to the community. This also ties into your assumption architecture, which I understand you are currently overhauling. Ideally, your types and assumptions should pretty much be one and the same. I would be happy to work with you to achieve these goals. I think SymPy is a cool project and nothing would make me happier than being able to help bridge the gap between performing operations on symbolic constructs and arbitrary code. I realize that the changes I've proposed are non-trivial; I hope you see their value the way I do :) Nathan Rice -- 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.
