> I think we should create a separate project for sympy.core as well.
> Below follow some thoughts about it.
>
> sympy.core is an important package for sympy and to get a good
> performance with it, special care is required when coding it.
> That means that implementing enhancements takes time.
>
> We have already seen that replacing a core in sympy is a
> painful process, especially when core has not stabilized properly.

Very painful indeed. :)

>
> Also I think working on sympy branch makes development quite fragile:
> in sympy project branches may come and go without discussing it with
> developer(s) who have created or worked on with these branches.
> One can live with that but that's not always nice.

If you are referring to the branch with the symbolic, I thought you
are ok with deleting it since we moved  to the new core - and I
offered to restore it and you said it's ok. Anyway, deleting/restoring
is just a matter of a few seconds with svn.

> I thing the good reason for separating the sympy core is that
> when the core has been improved and is stable and fast then it may take
> some time to update sympy packages to a new core version.
> Sometimes it is not even reasonable to switch to new core right a way,
> eg when certain features have not be implemented yet or new
> releases are coming up.
> But at the same time the new core would be useful for projects that require
> only basic symbolic manipulation features, not the whole machinery
> of sympy.
>
> I think there is a good parallelism with history of scipy/numpy projects:
> sympy.core is like numpy and sympy is like scipy. In scipy
> development we had had similar issues. Initally in scipy
> we used package trees like
>
>   scipy/core
>   scipy/packages
>   ..
> or
>
>   scipy_core (current numpy)
>   scipy/packages (current scipy)
>
> and finally today we have
>
>   numpy/
>   scipy/
>
> that are developed as separate packages but are closely
> related to each other.
>
> To skip analogous development in sympy, we should have separate
> packages like
>
>   symlib/ (current sympy/sandbox/core)
>   sympy/  (current sympy without sympy.core)
>
> where sympy imports symlib and checks that symlib has proper version.
> When we get this working then I believe that development of both
> sympy and symlib will be easier.

Yes, the problem with the trunk is, that one need to make sure he
doesn't break things and also that all the other developers agree with
changes, thus one needs to discuss everything in Issues first, so that
everyone can talk into it.  Which I think is good for the trunk.

However, we also need to try completely new ideas and just play, to
see what is good and what is not, and to do that, it needs to be done
in a separate branch/project. I like that you just try a new idea and
see how it goes. I myself am usually very skeptical if it is too
complex at first sight, because I want to keep sympy simple - so that
anyone can easily use it, contribute, fix things etc.

So I welcome that you are still not satisfied with the current core
(neither am I) and want to improve it. And the only way how to do it,
imho, is exactly as you are doing, just forget about any
compatibility, learn from mistakes and do it better.

Now to technical things - I am not sure it's that simple as with
scipy, where the only thing needed is just arrays, right? In sympy
it's basically everything. I would like it to be like a very well
defined core (that can later be written in C++ optionally for speed),
but I don't know how to do it, because it always ends up depending on
everything. :) Like, if we want complex exponentials in the core, then
sin/cos creeps in. If we want a good series expansion - the limits
shouldn't be needed, but sometimes it's much easier to use them in the
series expansion code.

The goals of sympy are clear, whatever we can do to meet them, either
by adapting sympy to the new core and moving it in, or just taking
parts of it that we like and implementing them in steps, I am fine
with that.

Ondrej

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

Reply via email to