Sympycore: basic structure stable yet?
andy
Hi All,
I have some time over the next couple of weeks to experiment with
ideas related to Sympy, and a project of mine.
When I last tried Sympy I had problems with functions, lambdas etc.
If Sympycore is the future core for Sympy I'm keen to work with it
right from the start. Is the basic class structure in Sympycore
reasonably settled now? I mean the basic stuff: Pow, Add, Mul classes,
and defining functions, lambdas etc?
Many thanks,
andy
Pearu Peterson
On Dec 8, 11:53 am, andy <and...@hotmail.com> wrote:
> Hi All,
>
> I have some time over the next couple of weeks to experiment with
> ideas related to Sympy, and a project of mine.
> When I last tried Sympy I had problems with functions, lambdas etc.
> If Sympycore is the future core for Sympy I'm keen to work with it
> right from the start. Is the basic class structure in Sympycore
> reasonably settled now? I mean the basic stuff: Pow, Add, Mul classes,
> and defining functions, lambdas etc?
anything
that is not working as expected, just file a new issue.
Btw, I am currently working on adding operator support to sympycore.
Pearu
Ondrej Certik
> > I have some time over the next couple of weeks to experiment with
> > ideas related to Sympy, and a project of mine.
What is your project about? I mean which exact features you need?
> > When I last tried Sympy I had problems with functions, lambdas etc.
> > If Sympycore is the future core for Sympy I'm keen to work with it
> > right from the start. Is the basic class structure in Sympycore
> > reasonably settled now? I mean the basic stuff: Pow, Add, Mul classes,
> > and defining functions, lambdas etc?
>
> Yes, I think so that the basic stuff is quite stable. If you find
> anything
> that is not working as expected, just file a new issue.
> Btw, I am currently working on adding operator support to sympycore.
It depends what you want. Pearu, as I understand it, wants to port
modules from SymPy to sympycore and then switch completely from sympy
to sympycore (possibly renaming it to sympy), the same way as we did
it the last time. While I disagree, because the way forward imho is to
improve SymPy, otherwise you'll get two very similar projects, some
things will be working in one, some other things in the other one.
Starting always from scratch is not the way forward imho.
You can read more about this issue here:
http://groups.google.com/group/sympy/browse_thread/thread/ffdb5468fe5a8356/
Quoting Pearu from there:
"
The issues that are considered difficult to resolve in the
current sympy (such as speed, assumptions model, caching issues)
become almost unresolvable within the current sympy development
policy (which btw is very good for a mature project).
"
So are those fundamental issues (speed, assumptions, caching) resolved
and settled in sympycore already? If so, let's discuss them and then
port them to sympy.
Ondrej
Pearu Peterson
On Dec 8, 1:12 pm, "Ondrej Certik" <ond...@certik.cz> wrote:
> It depends what you want. Pearu, as I understand it, wants to port
> modules from SymPy to sympycore and then switch completely from sympy
> to sympycore (possibly renaming it to sympy), the same way as we did
> it the last time.
sympy to sympycore. There is some work ahead to develop a
good assumption model.
My plan is to make sympycore a robust and extensible symbolic
manipulation core package. In order to achive this, we need to port
some modules from sympy in order to
1) test if the sympycore ideas are usable and efficient
2) have example modules illustrating how to extend the package
with new functionality, this includes support for sympy to start
using sympycore. Relevant modules are computational
modules and uninteresting modules for sympycore are those
that deal with pretty IO, for instance.
Pearu
Ondrej Certik
> sympy to sympycore. There is some work ahead to develop a
> good assumption model.
> My plan is to make sympycore a robust and extensible symbolic
> manipulation core package. In order to achive this, we need to port
> some modules from sympy in order to
> 1) test if the sympycore ideas are usable and efficient
> 2) have example modules illustrating how to extend the package
> with new functionality, this includes support for sympy to start
> using sympycore. Relevant modules are computational
> modules and uninteresting modules for sympycore are those
> that deal with pretty IO, for instance.
But don't you think this basically creates two competing projects? Do
you want that to happen?
The IO things are just bell and whistles, that are very easy to port.
The other stuff are very difficult to port and to achieve the exact
same functionality as sympy has. Basically things, that you are not
interested in (geometry?, graphing?, IO, maybe some other minor
stuff), are easy to port. The rest is just the whole sympy. We both
agree that the fundamental issues should be improved. We probably both
not yet know, if sympycore already fixes all of them, or still more
work needs to be done. But once sympycore achieves some basic
functionality, I don't think sympy can just use it. Sympycore is just
too much different. So we could port the rest of the modules from
sympy to sympycore. But that's not your plan, so I am confused about
your plan.
Ondrej
Pearu Peterson
On Dec 8, 2:00 pm, "Ondrej Certik" <ond...@certik.cz> wrote:
...
> you want that to happen?
the technical issues that needs to be resolved. Either of
the projects will not be able to compete with existing
CA systems if they don't resolve the fundamental issues
that we are facing in sympy/sympycore.
Some times fixing fundamental issues just needs a complete
rewrite and I think this is the case with the current sympy.
Sympy is currently well usable for introducing people to
starting to think that it is possible to do symbolic manipulations
in Python but I personally feel that sympy is too difficult improve
in terms of speed and robustness.
So, my fundamental plan is just to work on resolving the
technical issues and leave other issues to be resolved
by time.
Pearu
Ondrej Certik
> the technical issues that needs to be resolved. Either of
> the projects will not be able to compete with existing
> CA systems if they don't resolve the fundamental issues
> that we are facing in sympy/sympycore.
> Some times fixing fundamental issues just needs a complete
> rewrite and I think this is the case with the current sympy.
>
> Sympy is currently well usable for introducing people to
> starting to think that it is possible to do symbolic manipulations
> in Python but I personally feel that sympy is too difficult improve
> in terms of speed and robustness.
>
> So, my fundamental plan is just to work on resolving the
> technical issues and leave other issues to be resolved
> by time.
As to speed I think a rewrite in C/Cython will be necessary, Python is
imho too slow - how much faster is sympycore compared to sympy? Could
you please try to port Kent's FEM test to sympycore, to see how fast
it is in sympycore? In ginac, it's 0.3s, in sympy it's 2.4s. If we
could get to let's say 3x slower than ginac, that I think could be
fast enough, considering the advantage of being pure python.
As to robustness, this is something that imho just needs to be
improved iterativelly. Why do you think SymPy is difficult to improve
in terms of robustness? I don't think so.
Well, I am just trying us to work just on one project, not two. You
have implemented and are implementing many nice features in sympycore,
that cannot be used from sympy, until someone ports it. I am working
on some other things that cannot be used in sympycore, until someones
ports it. Now new people will implement something in sympy, but it
cannot be used in sympycore. Some other people will choose sympycore,
because they like it's faster (for example), they implement something
nice and again, it will not be possible to use it in sympy. I think
its a very bad situation and it is an issue.
It won't be an issue if neither I nor you wanted to get other people
involved. But I think both me and you want other people involved. So
we really should work just on one project, not two that are
incompatible. I agree we need to fix caching, speed etc. But renaming
classes and methods (otherwise doing the same thing), rearranging
modules just creates it difficult to port code from one project to
another.
Ondrej
andy
> Hi Andy,
>
> > > I have some time over the next couple of weeks to experiment with
> > > ideas related to Sympy, and a project of mine.
>
> What is your project about? I mean which exact features you need?
symbolic input and generate numerical solutions to ODEs, PDEs and
optimisation problems in a manner which allows for very general
coupling between equations / problems - perhaps via code generation.
(I'm *not* trying to reproduce finite element tools such as ELMER,
FeNics, ANSYS, OpenFOAM etc.)
Anyway, enough of the grand plan! *Initially*, I want to perform some
experiments to take sets of equations, etc. and examine them
couplings, dependencies, linearity/nonlinearity, etc in order to be
able to recognise suitable solution techniques. It's not a fully
developed set of ideas yet, just some initial experiments... So,
without thinking for too long, here's my 'wish list' of features (much
of which is already in both sympy and sympycore):
- robust pattern matching (very important),
- functions (including vector valued functions)
- lambdas,
- operators,
- basic calculus,
- vector calculus,
- basic matrix vector facilities,
- limits,
and eventually assumptions too. I need to be able to perform a range
of tests on expressions, so really robust pattern matching and a
simple way of traversing terms in equations is useful. I also feel I
need to understand (and contribute to) the core code for my work for
two reasons:
- In general I need to work without evaluating expressions (i.e. I
don't want input of the form d(f^2)/dx to expand automatically to
2*f*df/dx because I loose valuable information about the structure of
the equation - Sympy seems to do this, I haven't found out yet what
Sympycore does....). So I expect to need to play with the Sympy/
Sympycore core code.
- Unfortunately Lambdas don't work in Sympy - see Sympy issue 427,
which still failed yesterday. I would like to fix this for myself and
for the Sympy project, but I find the current Sympy core too complex
to debug myself. :-(
> It depends what you want. Pearu, as I understand it, wants to port
> modules from SymPy to sympycore and then switch completely from sympy
> to sympycore (possibly renaming it to sympy), the same way as we did
> it the last time. While I disagree, because the way forward imho is to
> improve SymPy, otherwise you'll get two very similar projects, some
> things will be working in one, some other things in the other one.
> Starting always from scratch is not the way forward imho.
uncertainty on how things will progress.... For my work speed is not
important, however, the simpler Sympycore code is probably easier for
me to work with as I don't currently need many of the existing
modules. However I'm open to recommendations...
Personally, I think that for a complex task such as symbolic maths in
Python it is unsurprising that as the authors gain experience better
ways of structuring the core become apparent.... Sympy seems to be very
young - so I don't mind at all if things break. I'm happy to be
patient, as having a really good core design will make development
much easier in the long run. So I understand and respect what Pearu is
doing (with Frederik and other's help). I also guess that this work
will not be 'complete' for some while...
However, I also see there is good code already in Sympy, and I agree
very strongly with Ondrej that it would be nice to have just one
project in the end. What would help both projects? Would it now help
if I tried to try convert some small Sympy modules to use Sympycore,
and to see how difficult this is? This would:
- help me learn about both projects and decide which to use
- help test Sympycore
- bring the day closer when Sympy can use the new core (without
distracting Pearu from developing the core itself).
Is it too early in Sympycore's development to do this, or not?
(Perhaps I need to wait another 2 months?) Obviously this work would
be done on the understanding that Sympycore may yet change in ways
that break this module code...
Best regards to all,
Andy
(Unfortunately, the last 3 times I tried to work on Sympy my day job
suddenly took over and needed all the time I hoped to have for working
with Sympy... so I can't promise much!)
Pearu Peterson
On Dec 9, 5:08 pm, andy <and...@hotmail.com> wrote:
> On Dec 8, 1:12 pm, "Ondrej Certik" <ond...@certik.cz> wrote:
> Anyway, enough of the grand plan! *Initially*, I want to perform some
> experiments to take sets of equations, etc. and examine them
> couplings, dependencies, linearity/nonlinearity, etc in order to be
> able to recognise suitable solution techniques. It's not a fully
> developed set of ideas yet, just some initial experiments... So,
> without thinking for too long, here's my 'wish list' of features (much
> of which is already in both sympy and sympycore):
>
> - robust pattern matching (very important),
with welldefined rules:
http://code.google.com/p/sympycore/wiki/PatternMatching
> - functions (including vector valued functions)
> - lambdas,
> - operators,
> - basic calculus,
work in progress, differentation and basic integration
work fine.
> - vector calculus,
> - basic matrix vector facilities,
> - limits,
> and eventually assumptions too. I need to be able to perform a range
> of tests on expressions, so really robust pattern matching and a
> simple way of traversing terms in equations is useful. I also feel I
> need to understand (and contribute to) the core code for my work for
> two reasons:
>
> - In general I need to work without evaluating expressions (i.e. I
> don't want input of the form d(f^2)/dx to expand automatically to
> 2*f*df/dx because I loose valuable information about the structure of
> the equation - Sympy seems to do this, I haven't found out yet what
> Sympycore does....). So I expect to need to play with the Sympy/
> Sympycore core code.
x=Symbol('x')
f = FunctionType('f')
d(f^2)/dx = Derivative(f(x)**2, Tuple(x,2), is_canonical=True)
or FDerivative(f**2, Tuple(1,2), is_canonical=True)
You can even do D((x,n))(f(x)**2) to represent n-th derivative of
f(x)**2 with respect to x, here n=Symbol('n') .
> - Unfortunately Lambdas don't work in Sympy - see Sympy issue 427,
> which still failed yesterday. I would like to fix this for myself and
> for the Sympy project, but I find the current Sympy core too complex
> to debug myself. :-(
>>> x=Symbol('x')
>>> f=Lambda(x,x*3)
>>> f
Lambda((_x,), 3*_x)
>>> f(x)
3*x
(Warning: Lambda lacks fdiff method at the moment, fill fix it soon..)
> However, I also see there is good code already in Sympy, and I agree
> very strongly with Ondrej that it would be nice to have just one
> project in the end. What would help both projects? Would it now help
> if I tried to try convert some small Sympy modules to use Sympycore,
> and to see how difficult this is? This would:
>
> - help me learn about both projects and decide which to use
> - help test Sympycore
> - bring the day closer when Sympy can use the new core (without
> distracting Pearu from developing the core itself).
>
> Is it too early in Sympycore's development to do this, or not?
developed in sympycore to sympy.
Regards,
Pearu
Ondrej Certik
> symbolic input and generate numerical solutions to ODEs, PDEs and
> optimisation problems in a manner which allows for very general
> coupling between equations / problems - perhaps via code generation.
> (I'm *not* trying to reproduce finite element tools such as ELMER,
> FeNics, ANSYS, OpenFOAM etc.)
Thanks. This is the area of interest of most of us.
> - Unfortunately Lambdas don't work in Sympy - see Sympy issue 427,
> which still failed yesterday. I would like to fix this for myself and
> for the Sympy project, but I find the current Sympy core too complex
> to debug myself. :-(
Could you please give me more details on this? I would like SymPy to
be simple again, as it used to be before the merge to the new core.
In which areas do you find SymPy more complex than sympycore?
> > - help me learn about both projects and decide which to use
> > - help test Sympycore
> > - bring the day closer when Sympy can use the new core (without
> > distracting Pearu from developing the core itself).
> >
> > Is it too early in Sympycore's development to do this, or not?
>
> Not at all, in fact, sympy is already porting many features
> developed in sympycore to sympy.
I think it is a huge waste of our time to port both from sympycore to
sympy and from sympy to sympycore. I think we
should work on one project.
Ondrej