Calculus module

[GoogleCodeExporter]

I created the calculus directory. To reiterate, I believe this subpackage
should be the home of the following:

order terms
limits
integrals
sums
products
differential equations
difference equations

Basically anything involving limits (except special functions, which go in
functions).

Sums, products and difference equations may seem out of place, because they
are not inherently based on limits. However, practically speaking, they are
often used with limits (e.g. for infinite summation or sometimes even for
finding closed form solutions in finite cases), and from a functional point
of view, having them all in one place makes sense. WxMaxima also groups
these operations under "calculus" (but then, wxMaxima places polynomial
operations under "calculus" as well, so that's perhaps not to be relied on
too much). This can be discussed, of course.

More importantly, I created a base class that can be used to implement
calculus operators. The idea is that we should be able to use symbolic
integrals etc as part of normal expressions, for example t =
5*Integral(x**x, (x, 2, 3)); t.evalf(), and the CalculusOperator is
intended to capture basic functionality needed for that. All operators
don't work exactly the same way, though, so this class won't be able to do
everything.

I also added the basic polynomial integration function discussed in the
sympy issues. We should combine with a table lookup and then port the Risch
algorithm implementation from sympy-stable.

More urgently, however, we need O, series and limits, since those are
needed to implement almost everything else.

Original issue reported on code.google.com by fredrik....@gmail.com on 3 Dec 2007 at 5:51

[GoogleCodeExporter]

Isn't it better to do these changes in SymPy instead? Or do you think it's 
better to
do it in sympycore first, to see if it is good and then port it to sympy? I 
don't
like that sympy and sympycore goes more and more apart. 

What exact features do you want to have in sympycore? I thought it's just the 
basic
functionality. I think that by porting everything and with the different 
internals,
as it is now, we will simply have two incompatible symbolic manipulation 
libraries in
Python, doing almost the same things, differently. That would be bad imho.

Original comment by ondrej.c...@gmail.com on 3 Dec 2007 at 6:04

[GoogleCodeExporter]

I don't see a problem of doing basic calculus stuff in sympycore
because it is an application of sympycore functionality and therefore
is like a test case to prove its usability. Since limits, integrals
need an assumption model then implementing basic functionality of
limits, integrals in sympycore is a proper place todo. We just need to keep
user interfaces more or less compatible between sympy and sympycore.

Another note: I would probably have derived CalculusOperator from
(BasicArithmetic, BasicFunction) (similar to how Function is derived)
since sometimes it makes sense to carry out arithmetic operations
with operators without specifying its arguments. But we can do it later
when the real need emerges.

Original comment by pearu.peterson on 3 Dec 2007 at 6:23

[GoogleCodeExporter]

I do think that porting sympy "library" modules to sympycore will be easier than
merging sympycore back into sympy. However, right now I only want to copy a few
modules and tweak them until they run, and Risch would be a good example. The 
goal is
*not* to port all of sympy to sympycore, nor to extend the ported code with new
features that are not present in sympy, just to check that the new core can 
support
them. Some changes have to be made for compatibility and consistency.

As I said, the most important features for the calculus module are O and
limits/series, since these need to interact in a rather fundamental way with the
core, and also with the to-be-developed assumption system.

By the way, as a small step towards the future merger, I think it might be wise
already now to change the module structure in sympy to look more like the one in
sympycore.

Original comment by fredrik....@gmail.com on 3 Dec 2007 at 6:49

[GoogleCodeExporter]

> Since limits, integrals need an assumption model then implementing basic
functionality of limits, integrals in sympycore is a proper place todo.

Precisely.

> Another note: I would probably have derived CalculusOperator from
> (BasicArithmetic, BasicFunction) (similar to how Function is derived)
> since sometimes it makes sense to carry out arithmetic operations
> with operators without specifying its arguments. But we can do it later
> when the real need emerges.

Good point. I don't see an immediate need, but it'd be neat later on if you 
could do
e.g. Sqrt(Derivative) to get a fractional-order differential operator.

Original comment by fredrik....@gmail.com on 3 Dec 2007 at 6:53

[GoogleCodeExporter]

> By the way, as a small step towards the future merger, I think it might be 
wise
> already now to change the module structure in sympy to look more like the one 
in
> sympycore.

Agree. 

Original comment by ondrej.c...@gmail.com on 6 Dec 2007 at 1:35

[GoogleCodeExporter]

> I do think that porting sympy "library" modules to sympycore will be easier 
than
> merging sympycore back into sympy.

I don't think so. When we merged the library modules to the new core the last 
time,
we didn't achieve the full functionality of the old core till now (almost 5 
months
later), i.e. there are still many bugs in the series, hard to debug.

Original comment by ondrej.c...@gmail.com on 6 Dec 2007 at 10:14

[GoogleCodeExporter]

I think both ways are not easy.

But porting sympy functionality to sympycore has an advantage of
getting code "right" at the first time.

The other option, porting sympycore to
sympy, has a problem of mixing old and new style code
which introduces unnecessary burden of making the codes
work with each other, and this means extra code and effort,
and frustration from developers who wrote the original code but
may be do not fully understand why the code should be rewritten
with slightly another way to meat the requirements and features
of sympycore. The last issue is the main reason of documenting
the API in sympycore in as much detail as necessary (but not more)
for a developer to write a generic code.

Original comment by pearu.peterson on 7 Dec 2007 at 9:24

[GoogleCodeExporter]

Agree with the last paragraph. I would also add, that it's the other way round 
too -
developers of the new core don't want to mess up with sympy, because it needs 
extra
code and effort to pass all tests, to discuss and reach consensus on things 
etc. 

> But porting sympy functionality to sympycore has an advantage of
> getting code "right" at the first time.

I don't think sympycore or sympy is "right". I think "right" is when many 
developers,
at least 4, but better more, who wrote some code either to sympy or sympycore, 
sit
down and discuss every single feature, say I like this because of that, I don't 
like
that because of this etc. 

I mean - if there is just one main developer, it's fine if he makes the 
decisions
himself. But I don't want sympy to be such a thing.

I think what will happen, as I wrote in the email right when you started 
sympycore,
is that you will port most of the modules from sympy to sympycore and we will 
have
two, mostly identical, but not the same symbolic manipulation libraries in 
python. As
I wrote, I don't want this to happen, but I think it will happen. So I think 
it's
fair to say this clearly in advance.

One huge disadvantage is, that new people will then have to decide, if they 
want to
contribute to sympycore or sympy and when they choose one, the other community 
will
not directly benefit from it, until someone reimplements the same feature in the
other project. 

But at least we should imho try to discuss design features together in both 
projects,
so that it is not that difficult to port things from one project to another.

Original comment by ondrej.c...@gmail.com on 7 Dec 2007 at 10:31

[GoogleCodeExporter]

I did not mean that sympycore way is the right way
(though it has less fundamental issues than in sympy, imho)
but I meant that in sympycore we do things mostly from
scratch and have an opportunity to change internals
immidiately when something does not feel right or
some better idea emerges.
This is not possibly with sympy because of the extra
work/time that might turn to useless.

May be need to organize meetings where all developers
could come together and discuss ideas. I know that
you are going to have code sprint soon but unfortunately
I cannot travel at least two months because of broken
leg.. If there is enough interest then I believe that
such meetings could be held also in Simula.

Original comment by pearu.peterson on 7 Dec 2007 at 11:12

[GoogleCodeExporter]

I don't think I'll be able to attend the late December sprint either. But I can
easily make it to Simula -- Oslo is only a little over 5 hours from here by 
train.

Original comment by fredrik....@gmail.com on 7 Dec 2007 at 11:28

[GoogleCodeExporter]

Or even easier, 4 hours by bus.

Original comment by fredrik....@gmail.com on 7 Dec 2007 at 11:31

[GoogleCodeExporter]

Yes, let's do a meeting, I recently was at SAGE and Debian meetings (coding 
sprints)
and this really improves relationships and also a lot of work gets done.

I can go to Simula, no problem with that. There is also Ola and Kent in there.

But back to topic - yes, it's nice that it's easy to test and implement new 
ideas in
sympycore. But once sympycore stops being a research project and starts having 
some
functionality, that just cannot be broken, it will have the same problem as 
sympy
has. I don't think it's a problem, it's just inevitable. 

And the only way to do things, imho, is to have one project - be it sympy or
sympycore - with the maximum features, where all developers just work on it and
commit things to that one project (instead of starting over and over from 
scratch). 

Original comment by ondrej.c...@gmail.com on 7 Dec 2007 at 2:04

[GoogleCodeExporter]

(starting from scratch is necessary to get the fundamental problems right, but I
believe then it needs to be integrated to the one main project - be it old core
sympy, new core sympy or sympycore)

Original comment by ondrej.c...@gmail.com on 7 Dec 2007 at 2:06