sympycore project
Pearu Peterson
I have moved the development of sympy/sandbox to a new project
sympycore:
http://code.google.com/p/sympycore/
as there is lots of work ahead to improve the assumptions model among
other
things and much faster core in sympycore is already usable for many
applications.
The plan is to keep copying code from sympy project minimal so that it
would be easier
to keep track on the new improved features in sympycore and not to mix
old coding techniques with new ones.
Best regards,
Pearu
Fredrik Johansson
Seems like a viable approach. Could you add me as a developer?
Fredrik Johansson
Pearu Peterson
On Oct 16, 8:29 am, "Fredrik Johansson" <fredrik.johans...@gmail.com>
wrote:
>
> Seems like a viable approach. Could you add me as a developer?
Sure. Done.
Pearu
Ondrej Certik
Indeed the SymPy's motivation is to have something usable now and it's
true that I am more concerned with functionality rather than with
speed. But I would like to have just one symbolic library in Python,
not two with slightly different ways of doing things. Of course if
there were problems with deciding how to implement things, it would
make sense to have two projects, each doing it differently - but I
don't think that's the case. I only require each thing to be discussed
first.
So it would be good if we could reuse most of the work you do, but
that means someone needs to implement it back in SymPy. If that
happens, it's fine. If we manage to disentagle the core from the rest
of SymPy, that'd be of course awesome. But as I said earlier, I am
quite skeptical on this -- and I don't want it to end up in a way that
sympycore will have some very nice features and speed that SymPy
doesn't and SymPy will have some very nice functionality that
sympycore doesn't and it will be impossible to merge it, so that one
could either use one or the other. That could happen easily, because
we may realize we don't have time to merge all the sympycore with
SymPy as well as you may realize you don't have time to merge all
SymPy with sympycore. That way we would fail to build a car and just
endup with two incompatible components.
That's why I want to integrate SymPy closely with SAGE, so that people
can use just one tool. But it makes sense to have SymPy as a separate
project, because it's pure Python and small and I like the philosophy
of having one small tool doing one job and doing it well. If we could
make SymPy depend on the sympycore, it also make sense to have it as a
separate, well defined project (that could possibly be rewritten in
C++/C), doing one job and doing it well.
Sorry for a longer email, I just wanted to make sure we try to avoid
some common pitfalls.
Ondrej
Pearu Peterson
I understand your concerns on the dangers of having two similar
projects. However, I think it would be impossible for me to
develop the core within the restrictions of the sympy
policy for several reasons that I'll discuss below.
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).
Nobody knows what is the best way to resolve these issues,
therefore one must experiment and that may temporarily break lots of
code.
This is not reasonable with the current state of sympy. This situation
of
changing-the-core-without-breakage will never get
better and so solving the hard issues within sympy policy is quite
impossible.
I agree that discussing changes is a good thing. We have
discussed quite alot what are the fundamental issues in sympy
and proposed possible ways of resolving these.
As a rule, fixing fundamental issues require fundamental changes.
I think it is time to start implementing them and sympycore
is a proper place to do it.
I have spent lots of effort on sympycore by now (in fact
more than I planned initially) and I can say that I see light:)
At the moment it is too early to discuss about merging
sympycore to sympy but when the time is ready, I think
the merge will not be as painful as the first one.
Regards,
Pearu
Ondrej Certik
I agree. I am more of a guy who wants new features and new stuff and
have something now, rather than tomorrow, even if it is not perfect -
and so I am glad you are trying to fix/improve the fundamental issues,
because I am more concentrating on new functionality and not breaking
things that work, some of which should really be refactored. I
updated the sympy's webpage, I tried to wrote the motivation behing
sympycore to http://code.google.com/p/sympy/wiki/SymPyCore (linked
from the frontpage). If you could please adjust it if I wrote
something not accurate, it'd be nice.
As to myself, I am currently busy at school and work, as everyone. :)
But my nearest plan is to implement the _sage_ methods and try to
integrate SymPy with SAGE more closely, so that we can discuss more
details on the SAGE days 6 in Bristol in 3 weeks.
Ondrej