Discussion of sympy - a symbolic math library for python

Aaron Meurer | 1 Feb 2012 21:18

Re: SymPy with generic Symbol proxies; python expression algebra

Hi.

On Tue, Jan 31, 2012 at 4:38 PM, Nathan Rice
<nathan.alexander.rice@...> wrote:
> 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).

This is cool.  Where can I get the code for these projects? I didn't
see any download links (I know I can pip install, but I want to play
with the code too).

>
> 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.

So I'm trying to understand exactly what you are suggesting here?  You
want to do the sort of thing that SymPy does where you can build up

(Continue reading)

headers

Nathan Rice | 1 Feb 2012 23:44

Re: SymPy with generic Symbol proxies; python expression algebra

> On Tue, Jan 31, 2012 at 4:38 PM, Nathan Rice
> <nathan.alexander.rice@...> wrote:
>> 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).
>
> This is cool.  Where can I get the code for these projects? I didn't
> see any download links (I know I can pip install, but I want to play
> with the code too).

My bad:

https://github.com/nathan-rice/Constraints
https://github.com/nathan-rice/Elementwise

>>
>> 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.

(Continue reading)

headers

Aaron Meurer | 2 Feb 2012 00:31

Re: SymPy with generic Symbol proxies; python expression algebra

On Wed, Feb 1, 2012 at 3:44 PM, Nathan Rice
<nathan.alexander.rice@...> wrote:
>> On Tue, Jan 31, 2012 at 4:38 PM, Nathan Rice
>> <nathan.alexander.rice@...> wrote:
>>> 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).
>>
>> This is cool.  Where can I get the code for these projects? I didn't
>> see any download links (I know I can pip install, but I want to play
>> with the code too).
>
> My bad:
>
> https://github.com/nathan-rice/Constraints
> https://github.com/nathan-rice/Elementwise

Cool.  So you are basically letting Python do the work by putting
everything in lambdas (or is it nested lambdas?).  SymPy builds things
up in it's own proxy objects, which has advantages (e.g., we can
easily print the object as it was built). I'm sure there are
advantages to just using Python closures, though I can't think of them
now (perhaps more space efficient, and simpler code?).

>
>>>
>>> I'm getting in touch because:
>>>

(Continue reading)

headers

Joachim Durchholz | 2 Feb 2012 01:05

Re: SymPy with generic Symbol proxies; python expression algebra

Am 02.02.2012 00:31, schrieb Aaron Meurer:
> Cool.  So you are basically letting Python do the work by putting
> everything in lambdas (or is it nested lambdas?).  SymPy builds things
> up in it's own proxy objects, which has advantages (e.g., we can
> easily print the object as it was built).

I may be displaying my Pythonic ignorance showing here, but wouldn't it 
be possible to change the print function for these lambdas?
Alternatively, the proxies could be made into Callables by attaching the 
proper function stuff.

As far as I understand Python, both variants should work equally well 
from the interpreter's point of view, so we'd be free to choose either 
route.

I have to admit I don't have a good idea about the gap between Nathan's 
propsal and current SymPy code, so YMMV.
Just my 2 cents 

--

-- 
You received this message because you are subscribed to the Google Groups "sympy" group.
To post to this group, send email to sympy@...
To unsubscribe from this group, send email to sympy+unsubscribe@...
For more options, visit this group at http://groups.google.com/group/sympy?hl=en.

headers

Nathan Rice | 2 Feb 2012 03:32

Re: SymPy with generic Symbol proxies; python expression algebra

> Cool.  So you are basically letting Python do the work by putting
> everything in lambdas (or is it nested lambdas?).  SymPy builds things
> up in it's own proxy objects, which has advantages (e.g., we can
> easily print the object as it was built). I'm sure there are
> advantages to just using Python closures, though I can't think of them
> now (perhaps more space efficient, and simpler code?).

Depends on whether you're talking about elementwise or constraints.
Constraints basically converts everything to a one argument callable,
so that you can evaluate each expression in the context of an input
value.  Elementwise uses lambdas to put off dereferencing variables
until the last possible moment, and to get around the fact that
standard generators are one shot items.

Also, note that  <at> 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

(Continue reading)

headers

Aaron Meurer | 2 Feb 2012 18:51

Re: SymPy with generic Symbol proxies; python expression algebra

On Wed, Feb 1, 2012 at 7:32 PM, Nathan Rice
<nathan.alexander.rice@...> wrote:
>> Cool.  So you are basically letting Python do the work by putting
>> everything in lambdas (or is it nested lambdas?).  SymPy builds things
>> up in it's own proxy objects, which has advantages (e.g., we can
>> easily print the object as it was built). I'm sure there are
>> advantages to just using Python closures, though I can't think of them
>> now (perhaps more space efficient, and simpler code?).
>
> Depends on whether you're talking about elementwise or constraints.
> Constraints basically converts everything to a one argument callable,
> so that you can evaluate each expression in the context of an input
> value.  Elementwise uses lambdas to put off dereferencing variables
> until the last possible moment, and to get around the fact that
> standard generators are one shot items.

I saw that they were both using lambda, though I didn't try to follow
all the decorator and metaclass logic to see what exactly happens with
each.

>
> Also, note that  <at> 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

(Continue reading)

headers

Ronan Lamy | 2 Feb 2012 20:13

Re: SymPy with generic Symbol proxies; python expression algebra

Le jeudi 02 février 2012 à 10:51 -0700, Aaron Meurer a écrit :

> Unfortunately, right now, SymPy is unbearably slow in PyPy, so this
> would definitely be a roadmap thing.

No, it isn't, see for instance
http://speed.pypy.org/timeline/#/?exe=3,6,1,5&base=2
+472&ben=sympy_expand&env=1&revs=200&equid=off
It's only testing sympy that is unbearably slow on PyPy, but actually
using it should give about the same speed as on CPython. 

--

-- 
You received this message because you are subscribed to the Google Groups "sympy" group.
To post to this group, send email to sympy@...
To unsubscribe from this group, send email to sympy+unsubscribe <at> googlegroups.com.
For more options, visit this group at http://groups.google.com/group/sympy?hl=en.

headers

Nathan Rice | 2 Feb 2012 23:21

Re: SymPy with generic Symbol proxies; python expression algebra

>> Also, note that  <at> 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,

(Continue reading)

headers

Aaron Meurer | 4 Feb 2012 00:18

Re: SymPy with generic Symbol proxies; python expression algebra

On Thu, Feb 2, 2012 at 3:21 PM, Nathan Rice
<nathan.alexander.rice@...> wrote:
>>> Also, note that  <at> 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?

(Continue reading)

headers

Andy Ray Terrel | 12 Feb 2012 13:31

Re: SymPy with generic Symbol proxies; python expression algebra

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.

-- Andy

On Fri, Feb 3, 2012 at 5:18 PM, Aaron Meurer <asmeurer@...> wrote:
> On Thu, Feb 2, 2012 at 3:21 PM, Nathan Rice
> <nathan.alexander.rice@...> wrote:
>>>> Also, note that  <at> 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

(Continue reading)

headers

Nathan Rice | 13 Feb 2012 15:33

Re: SymPy with generic Symbol proxies; python expression algebra

On Sun, Feb 12, 2012 at 7:31 AM, Andy Ray Terrel
<andy.terrel@...> 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.

(Continue reading)

headers

Aaron Meurer | 13 Feb 2012 23:54

Re: SymPy with generic Symbol proxies; python expression algebra

On Mon, Feb 13, 2012 at 7:33 AM, Nathan Rice
<nathan.alexander.rice@...> wrote:
> On Sun, Feb 12, 2012 at 7:31 AM, Andy Ray Terrel
<andy.terrel@...> 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

(Continue reading)

headers

Nathan Rice | 14 Feb 2012 01:22

Re: SymPy with generic Symbol proxies; python expression algebra

>> 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.

I like to solve problems completely, so I will find a solution :)

> 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).

Because in place operators are statements in python (even though it is
computable as an expression), you have to generate ast that looks
something like this:

Module([
    AugAssign(
        Name('x', Store()),
        Add(),
        Num(1)
    ),
    Expr(
        BinOp(
            Name('x', Load()),
            Mult(),

(Continue reading)

headers

Nathan Rice | 26 Feb 2012 16:47

Re: SymPy with generic Symbol proxies; python expression algebra

I have this at a pretty workable state.  It is available at
https://github.com/nathan-rice/symbolic.

Python's AST is not terribly fun to use, though I've done most of the
hard work.  There were a lot of corner cases and little annoyances.  I
still think the code transformation approach has promise, but I
definitely had to force myself to work on it at several points.

Has anyone here played with term rewriting software?  I'm interested
in hacking up a little term rewriting system for proofs and simple
general computation.  Suggestions for a good model to start from would
be appreciated.

Nathan

--

-- 
You received this message because you are subscribed to the Google Groups "sympy" group.
To post to this group, send email to sympy@...
To unsubscribe from this group, send email to sympy+unsubscribe@...
For more options, visit this group at http://groups.google.com/group/sympy?hl=en.

headers

Joachim Durchholz | 26 Feb 2012 18:06

Re: SymPy with generic Symbol proxies; python expression algebra

Am 13.02.2012 23:54, schrieb Aaron Meurer:
> In other words,
> something like x*(x += 1) would be allowed (e.g., if x starts as 2,
> this would give 3).

You do not want to have or allow side effects in user-specified 
expressions. You get a whole lot of restrictions on which AST 
transformations are safe and which aren't. I'm not sure how much of the 
integral solvers would be applicable if one of, say, the integration 
bounds contained an increment operator.
Also, users will be unclear about when exactly the increment happens. 
Heck, even programmers tend to avoid this kind of code, because it 
doesn't spell clearly out what it's doing.

Heck, I'd even make the mutating operations on all symbols throw an 
exception. Math is about immutable stuff, you are not supposed to 
redefine the meaning of a symbol in mid-flight.

--

-- 
You received this message because you are subscribed to the Google Groups "sympy" group.
To post to this group, send email to sympy@...
To unsubscribe from this group, send email to sympy+unsubscribe@...
For more options, visit this group at http://groups.google.com/group/sympy?hl=en.

headers

Sergiu Ivanov | 26 Feb 2012 20:05

Re: SymPy with generic Symbol proxies; python expression algebra

On Sun, Feb 26, 2012 at 7:06 PM, Joachim Durchholz <jo@...> wrote:
> Am 13.02.2012 23:54, schrieb Aaron Meurer:
>>
>> In other words,
>> something like x*(x += 1) would be allowed (e.g., if x starts as 2,
>> this would give 3).
>
> Heck, I'd even make the mutating operations on all symbols throw an
> exception. Math is about immutable stuff, you are not supposed to redefine
> the meaning of a symbol in mid-flight.

As a functional programming beginner and fan, I can't but agree.  I
was actually quite happy when I heard for the first time that SymPy
had immutable core, because that allows for much clearer and better
structured code (at least I see it so).

I'd like to ask the question which I believe to be very important:
what would be the benefit of having a mutable core?  Is it going to
provide some essential speed-up?  I am quite sure that there should be
a very serious reason to abandon the current immutability, because
this decision will immediately make the code more difficult to
maintain.

Sergiu

--

-- 
You received this message because you are subscribed to the Google Groups "sympy" group.
To post to this group, send email to sympy@...
To unsubscribe from this group, send email to sympy+unsubscribe@...
For more options, visit this group at http://groups.google.com/group/sympy?hl=en.

(Continue reading)

headers

Joachim Durchholz | 26 Feb 2012 22:58

Re: SymPy with generic Symbol proxies; python expression algebra

Am 26.02.2012 20:05, schrieb Sergiu Ivanov:
> As a functional programming beginner and fan, I can't but agree.  I
> was actually quite happy when I heard for the first time that SymPy
> had immutable core, because that allows for much clearer and better
> structured code (at least I see it so).

Hm... there's the question what an "immutable core" actually is. Is it 
the mathematical objects that the user sees, or is it an internal API 
for programmers?

In the former case, I'd avoid mutability. It's just a conceptual hassle, 
it makes semantics-preserving transformations harder (as soon as 
references are involved, prohibitively hard for a project of SymPy's 
scale - you need alias analysis, and compiler teams spend person-decades 
on that kind of stuff).

In the latter case, there's nothing wrong with it. Sure, coding just 
with immutable data is fun and far less error-prone, but Python is not 
built for that coding style; I suspect such code would be very clean but 
not very efficient.

> I'd like to ask the question which I believe to be very important:
> what would be the benefit of having a mutable core?

That's an interesting question, yes.
And the first one that should be asked whenever important changes are 
undertaken, and the first one to look for an answer for.

Just my 2c.

(Continue reading)

headers

krastanov.stefan-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org | 27 Feb 2012 03:35

Re: SymPy with generic Symbol proxies; python expression algebra

I would like to point out that the immutability of the core need not
change if we follow the propositions in this discussion.

In my opinion the important point here is the implementation of
abstract syntax trees for sympy. The minor (from mathematical point of
view) details about whether it should be immutable tree or whether
side effects and assignments should be allowed in the tree (hopefully
not!) are secondary.

The use of ASTs seems like the right way to fix
http://code.google.com/p/sympy/issues/detail?id=1941

We can have identity crawler that does not change the tree (just
returns a copy). The current crawlers (just what Add and Mul do, but
much better abstracted). Simplification and canonization crawlers.
Special crawler options specific to an object (Units subclass politely
asking the crawler to be placed last). Now every time that we need
some canonization we subclass Expr. It is not a scalable solution at
all.

Example:
Special treatment of Units in Mul
The subclassed Quantum Expr in the quantum module.
The need for MatExpr, MatAdd, MatMul... It is a good solution for the
current state of the code but it is ugly and it does not scale (what
happens when I want both matrices and kets in my expression?)

The existence of AST would make the implementation of abstract
multilinear algebra or group theory much easier as there won't be any
need for subclassing Expr. Just writing a crawler for the tree should

(Continue reading)

headers

Matthew Rocklin | 27 Feb 2012 18:47

Re: SymPy with generic Symbol proxies; python expression algebra

The Theano project that might be relevant in this discussion.

Theano is a python project that represents array computation as an abstract syntax tree of symbolic objects. It has a series of "optimizers" that walk over and change the graph on request. Its an interesting model and serves their purposes well.

On Sun, Feb 26, 2012 at 8:35 PM, krastanov.stefan-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org <krastanov.stefan-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> I would like to point out that the immutability of the core need not
> change if we follow the propositions in this discussion.
>
> In my opinion the important point here is the implementation of
> abstract syntax trees for sympy. The minor (from mathematical point of
> view) details about whether it should be immutable tree or whether
> side effects and assignments should be allowed in the tree (hopefully
> not!) are secondary.
>
> The use of ASTs seems like the right way to fix
> http://code.google.com/p/sympy/issues/detail?id=1941
>
> We can have identity crawler that does not change the tree (just
> returns a copy). The current crawlers (just what Add and Mul do, but
> much better abstracted). Simplification and canonization crawlers.
> Special crawler options specific to an object (Units subclass politely
> asking the crawler to be placed last). Now every time that we need
> some canonization we subclass Expr. It is not a scalable solution at
> all.
>
> Example:
> Special treatment of Units in Mul
> The subclassed Quantum Expr in the quantum module.
> The need for MatExpr, MatAdd, MatMul... It is a good solution for the
> current state of the code but it is ugly and it does not scale (what
> happens when I want both matrices and kets in my expression?)
>
> The existence of AST would make the implementation of abstract
> multilinear algebra or group theory much easier as there won't be any
> need for subclassing Expr. Just writing a crawler for the tree should
> be sufficient. It won't be less work, but the incompatibility between
> the subclasses of Expr will be evaded.
>
> On 26 February 2012 16:58, Joachim Durchholz <jo <at> durchholz.org> wrote:
>> Am 26.02.2012 20:05, schrieb Sergiu Ivanov:
>>
>>> As a functional programming beginner and fan, I can't but agree. I
>>> was actually quite happy when I heard for the first time that SymPy
>>> had immutable core, because that allows for much clearer and better
>>> structured code (at least I see it so).
>>
>>
>> Hm... there's the question what an "immutable core" actually is. Is it the
>> mathematical objects that the user sees, or is it an internal API for
>> programmers?
>>
>> In the former case, I'd avoid mutability. It's just a conceptual hassle, it
>> makes semantics-preserving transformations harder (as soon as references are
>> involved, prohibitively hard for a project of SymPy's scale - you need alias
>> analysis, and compiler teams spend person-decades on that kind of stuff).
>>
>> In the latter case, there's nothing wrong with it. Sure, coding just with
>> immutable data is fun and far less error-prone, but Python is not built for
>> that coding style; I suspect such code would be very clean but not very
>> efficient.
>>
>>
>>> I'd like to ask the question which I believe to be very important:
>>> what would be the benefit of having a mutable core?
>>
>>
>> That's an interesting question, yes.
>> And the first one that should be asked whenever important changes are
>> undertaken, and the first one to look for an answer for.
>>
>> Just my 2c.
>>
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "sympy" group.
>> To post to this group, send email to sympy-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org.
>> To unsubscribe from this group, send email to
>> sympy+unsubscribe <at> 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-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org.
> To unsubscribe from this group, send email to sympy+unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org.
> 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-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
To unsubscribe from this group, send email to sympy+unsubscribe <at> googlegroups.com.
For more options, visit this group at http://groups.google.com/group/sympy?hl=en.

headers

Sergiu Ivanov | 27 Feb 2012 20:15

Re: SymPy with generic Symbol proxies; python expression algebra

On Mon, Feb 27, 2012 at 4:35 AM, krastanov.stefan@...
<krastanov.stefan@...> wrote:
> I would like to point out that the immutability of the core need not
> change if we follow the propositions in this discussion.
>
> In my opinion the important point here is the implementation of
> abstract syntax trees for sympy. The minor (from mathematical point of
> view) details about whether it should be immutable tree or whether
> side effects and assignments should be allowed in the tree (hopefully
> not!) are secondary.

I see.  And indeed, I think it would be great to do without side
effects in the trees, because, as Joachim said, this is very likely to
induce plenty of hardship.

> The use of ASTs seems like the right way to fix
> http://code.google.com/p/sympy/issues/detail?id=1941

Yes, can't but agree.  ASTs seem to be the most generalised way of
achieving the desired functionality and it looks like not much effort
will be required to implement special cases.

> We can have identity crawler that does not change the tree (just
> returns a copy). The current crawlers (just what Add and Mul do, but
> much better abstracted). Simplification and canonization crawlers.
> Special crawler options specific to an object (Units subclass politely
> asking the crawler to be placed last). Now every time that we need
> some canonization we subclass Expr. It is not a scalable solution at
> all.

Crawlers seem to possess tremendous power; it would be great to have
them, obviously.

> Example:
> Special treatment of Units in Mul
> The subclassed Quantum Expr in the quantum module.
> The need for MatExpr, MatAdd, MatMul... It is a good solution for the
> current state of the code but it is ugly and it does not scale (what
> happens when I want both matrices and kets in my expression?)
>
> The existence of AST would make the implementation of abstract
> multilinear algebra or group theory much easier as there won't be any
> need for subclassing Expr. Just writing a crawler for the tree should
> be sufficient. It won't be less work, but the incompatibility between
> the subclasses of Expr will be evaded.

Indeed, crawlers seem to provide a relatively cheap solution to a wide
range of problems which are already arising in SymPy.

And yes, now I get the relationship between the main topic of the
thread and side-effects 

Sergiu

--

-- 
You received this message because you are subscribed to the Google Groups "sympy" group.
To post to this group, send email to sympy@...
To unsubscribe from this group, send email to sympy+unsubscribe@...
For more options, visit this group at http://groups.google.com/group/sympy?hl=en.

headers

Sergiu Ivanov | 27 Feb 2012 20:08

Re: SymPy with generic Symbol proxies; python expression algebra

On Sun, Feb 26, 2012 at 11:58 PM, Joachim Durchholz <jo@...> wrote:
> Am 26.02.2012 20:05, schrieb Sergiu Ivanov:
>
>> As a functional programming beginner and fan, I can't but agree.  I
>> was actually quite happy when I heard for the first time that SymPy
>> had immutable core, because that allows for much clearer and better
>> structured code (at least I see it so).
>
>
> Hm... there's the question what an "immutable core" actually is. Is it the
> mathematical objects that the user sees, or is it an internal API for
> programmers?

I thought it referred to the fact that SymPy is immutable "in the
large"; i.e., side-effects are allowed on a small scale (some simple
flags, counters, etc.), but separate entities stay away from
modifications.  At least, this is my (very basic) understanding of how
SymPy is organised.

> In the former case, I'd avoid mutability. It's just a conceptual hassle, it
> makes semantics-preserving transformations harder (as soon as references are
> involved, prohibitively hard for a project of SymPy's scale - you need alias
> analysis, and compiler teams spend person-decades on that kind of stuff).

Yes, that's precisely what I meant, but expressed with better
terminology and more detail 

> In the latter case, there's nothing wrong with it. Sure, coding just with
> immutable data is fun and far less error-prone, but Python is not built for
> that coding style; I suspect such code would be very clean but not very
> efficient.

Yes, I get it; I'd say what I meant when I joined the discussion was
something more similar to the former case of the two you describe.

Sergiu

--

-- 
You received this message because you are subscribed to the Google Groups "sympy" group.
To post to this group, send email to sympy@...
To unsubscribe from this group, send email to sympy+unsubscribe <at> googlegroups.com.
For more options, visit this group at http://groups.google.com/group/sympy?hl=en.