Re: symbolic manipulation in python
Ondrej Certik
I discovered Pearu Peterson's code for symbolic manipulation, so I am
moving my conversation with him to the mailinglist.
"
I have currently
only a draft of its tutorial online (see pdf below file
for more update features):
http://docs.google.com/Doc?id=ddx7h2wm_1cpw4n5
and newly started tutorial in pdf (uncomplete, see
online tutorial for most of the features). The
pdf file is in symbolic/doc directory (see the tar-ball).
I can share also the source now (I am in the progress of
cleaning up the code and that's why haven't put the
source out yet). Here is symbolic source tar-ball:
http://cens.ioc.ee/~pearu/symbolic.tgz
"
and my reply is below:
On 5/20/07, Pearu Peterson <pe...@cens.ioc.ee> wrote:
> On Sun, May 20, 2007 12:53 pm, Ondrej Certik wrote:
> > Hi Pearu,
> >
> > I looked at your code and the documentation, and yes, you made almost
> > the same decisions as we did. Only you seem to rely on string
> > representations too much.
> > In SymPy, we do:
> >
> > x = Symbol("x"), but from then on, we only work with x, not "x".
>
> This is same in symbolic. Once a Symbolic object is created, all
> manipulations are carried out with their instances. Maybe different
> from SymPy, I have turn lots of effort to properly parsing strings to
> construct Symbolic objects. I think this is important in applications
> as it is easier to write a complicated expression as a string
> rather than construct objects and doing manipulations with
> them. Eg compare
>
> x = Symbol("x")
> y = Symbol("y")
> expr = x**2 + y
>
> to
>
> expr = Symbolic("x**2 + y")
>
> Both are possible with symbolic but I am not sure if SymPy supports
> parsing strings.
SymPy doesn't yet have a parser to construct an expression from a
string. But it is a nice feature, we should implement it as well.
> > Do you think you could try SymPy and tell me your impressions? I am
> > very much interested in that, for example - what it cannot do that you
> > need, or what you don't like. Because we are more or less devising the
> > interface from scratch - other symbolic manipulation programs cannot
> > help us much, because the python interface is specific to python.
>
> Yes, I agree. I think both you and me have taken lots of ideas
> from GiNaC.
>
> > What are your intentions with your code? I mean - what is your aim. Is
> > your goal similar to SymPy's? If so, I would be interested in your
> > opinion about SymPy - what things you think we are doing right and
> > wrong etc.
>
> I think my goals are similar to SymPy. I have needed symbolic
> manipulations tools for implementing methods from soliton theory
> as well as parsing Fortran expressions and doing simple manipulations
> with them.
Exactly. I also wanted to take some complicated formula from some
article, play with it in sympy (simplify it, or plot it, etc.) and
then generate a fortran code from that. I also have other uses, like
playing in the general relativity, or quantum field theory. But
basically, compared to for example axiom, I just need the basic
calculus, but I need it very well supported.
> In past I have tried at least
> 5 different implementation ideas for doing symbolic manipulations
> in Python and my experience is that for performance it is crusial
> that very simple simplifications such as `x+0 -> x`, `x*0 -> x`
> should be carried out as small number of operations as possible.
> That's why I have in symbolic singleton classes like One, Zero,
> etc so that for testing if a symbolic instance x is equal to 1
> one needs the following code:
> isinstance(x, One)
In SymPy, those simplifications are evaluated automatically, so if you
type x+0, it simplifies to x, so then comparing x==x is trivial. I'll
have to look at your code again. But I think that x==1 is more
intuitive than isinstance(x, One). So when you simplify Integer to 1,
you retype it to One?
> Also, to avoid import issues of modules that may import
> each other, I think I have found a good solution: all symbolic
> classes will be attributes of a base class Symbolic that
> are set during importing the modules. Modules will import
> only Symbolic class and the code will have all classes from
> other modules via Symbolic class. The sympy approach, where
> you import modules in methods, is certainly possible but
> less efficient. For example, sympy.core modules may need more
> advanced methods from sympy.modules but with the current sympy setup
> this may lead to circular import issues.
>
> Btw, symbolic uses much faster algorithm for expanding powers.
>
> I think when comparing symbolic and sympy (I have not read sympy
> sources very well) then they share many ideas but have been
> focused on different problems in this early stage of development.
> I think we should get basic ideas implemented right in the
> beginning and then start building more advanced methods from that.
I actually think that important are only the test cases, because that
defines the interface. How you implement it is other thing and can
change in the future.
My philosophy is to have as much functionality implemented as
possible, quickly (possibly ugly, slowly) but using the right and
correct interface (defined by the test cases). And refactor is, when
the code is too fragile.
> I would suggest that first we should try to get number objects unified
> between sympy and symbolic. I think symbolic has a very complete
> support for different numbers such as decimal for arbitrary precision
> math as well as manipulations with symbols like infinity and
> imaginary unit and not-a-number. I also noticed
> that in sympy `oo+1` is not simplified to `oo`..
You found a bug, thanks. :)
> I think that the best way to understand differences between sympy
> and symbolic is to attapt unittests of one for the use of other.
That's why I wanted you to discuss it with us. It would be very nice
if we could discuss all the differences in symbolic and sympy. Becuase
finding a nice Python interface for symbolic manipulation is
challenging.
> Since you have a good development infrastructure set up for sympy
> then I don't mind moving symolic features to sympy. We might need
> to discuss other implementation decisions in more detail in future.
> How many people are accually developing sympy?
Me, Fabian, and then google summer of code students Mateusz, Jason,
Brian, Robert and soon also Chris. Also Jurgen contributed a nice
pretty printing system and sometimes others help us find a bug, or
discuss something.
If you have some particular points, we discuss them in Issues.
Otherwise you can use this mailinglist. It's nice that you took some
other approaches than we did, so that we can compare it.
> > For example about the pattern matching - you seem to do it using strings?
>
> I haven't fully implemented pattern matching yet (symbolic
> does not have wildsymbol yet). Pattern matching is used only in parser code
> but that is another problem.
>
> > In SymPy, it works like this:
> >
> > http://code.google.com/p/sympy/wiki/Tutorial
> >
> > (the last section). But currently, it is a little fragile.
>
> I have kept the same idea in my mind for pattern matching.
>
> Looking forward cooperating with you,
Great.
Ondrej
Pearu Peterson
> SymPy doesn't yet have a parser to construct an expression from a
> string. But it is a nice feature, we should implement it as well.
symbolic.parser should be easy to adapt to sympy.
> > In past I have tried at least
> > 5 different implementation ideas for doing symbolic manipulations
> > in Python and my experience is that for performance it is crusial
> > that very simple simplifications such as `x+0 -> x`, `x*0 -> x`
> > should be carried out as small number of operations as possible.
> > That's why I have in symbolic singleton classes like One, Zero,
> > etc so that for testing if a symbolic instance x is equal to 1
> > one needs the following code:
> > isinstance(x, One)
>
> In SymPy, those simplifications are evaluated automatically, so if you
> type x+0, it simplifies to x, so then comparing x==x is trivial. I'll
> have to look at your code again. But I think that x==1 is more
> intuitive than isinstance(x, One). So when you simplify Integer to 1,
> you retype it to One?
x==x and x==1 and x==Symbolic('1') work all also in symbolic, of course.
I agree that in user code one can use x==y but I meant that testing
equality to special numbers such as -1, 1, 0, oo, nan should be
efficient in low level code such as in performing elementary
simplifications of arithmetic operations.
symbolic automatically transforms all Python numbers to proper
symbolic numbers when performing operations with them. So,
using 1 for One() is ok.
> I actually think that important are only the test cases, because that
> defines the interface. How you implement it is other thing and can
> change in the future.
> My philosophy is to have as much functionality implemented as
> possible, quickly (possibly ugly, slowly) but using the right and
> correct interface (defined by the test cases). And refactor is, when
> the code is too fragile.
I agree. So there should be two types of tests: one testing the correctness
of interface and other testing the correctness of implementation details.
> > I think that the best way to understand differences between sympy
> > and symbolic is to attapt unittests of one for the use of other.
>
> That's why I wanted you to discuss it with us. It would be very nice
> if we could discuss all the differences in symbolic and sympy. Becuase
> finding a nice Python interface for symbolic manipulation is
> challenging.
Indeed.
I'll try to compose a summary of symbolic object models
both in symbolic and sympy.
Btw, why did you choose GPL licence for sympy? May I propose
something that is more relaxed licence model than GPL: LGPL or
BSD-like that numpy has?
Best regards,
Pearu
Ondrej Certik
> of interface and other testing the correctness of implementation details.
Or rather the correctness of the calculations. I view the tests as a
definition what the user wants from the package and what results he
wants to get and so by definition, what is not tested for, the user
doesn't want. And if we find that some feature really should be there
(the user wants it), we write a test.
> Indeed.
> I'll try to compose a summary of symbolic object models
> both in symbolic and sympy.
That would be great. You might be interested in this document:
http://code.google.com/p/sympy/wiki/HowItWorks
> Btw, why did you choose GPL licence for sympy? May I propose
> something that is more relaxed licence model than GPL: LGPL or
> BSD-like that numpy has?
I created the issue for that:
http://code.google.com/p/sympy/issues/detail?id=138
Let's discuss it there.
Ondrej