The Theano http://en.wikipedia.org/wiki/Theano_(Math_Compiler) 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
On Sun, Feb 26, 2012 at 11:58 PM, Joachim Durchholz j...@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
On Mon, Feb 27, 2012 at 4:35 AM, krastanov.ste...@gmail.com
krastanov.ste...@gmail.com 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
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
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
On Sun, Feb 26, 2012 at 7:06 PM, Joachim Durchholz j...@durchholz.org 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
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...
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
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
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
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
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 Thu, Feb 2, 2012 at 3:21 PM, Nathan Rice
nathan.alexander.r...@gmail.com wrote:
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
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,5base=2
+472ben=sympy_expandenv=1revs=200equid=off
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
Hi.
On Tue, Jan 31, 2012 at 4:38 PM, Nathan Rice
nathan.alexander.r...@gmail.com 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
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
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
18 matches
Mail list logo
