Nathan Rice

2012-01-31 23:38:22 UTC

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-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org

To unsubscribe from this group, send email to sympy+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org

For more options, visit this group at http://groups.google.com/group/sympy?hl=en.

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-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org

To unsubscribe from this group, send email to sympy+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org

For more options, visit this group at http://groups.google.com/group/sympy?hl=en.