Calculus in SAGE, motivations

[Ondrej Certik]

Hi,

I would like to discuss how to improve calculus in SAGE.

I know, that currently, most of the developers need other things more
urgently, but I think calculus will be the most frequently used part
in SAGE. For example all my friends and colleagues cannot really use
SAGE at the moment, because it cannot yet compete with Mathematica in
calculus. I would like this to be changed.

Ways to progress that come to my mind:

1) Expose as much Maxima functionality as possible (one example is
substitution of other things besides symbols).
2) It's important to allow users to create their own functions and the
calculus package should be able to work with them. Maybe it will by
possible to hack the Maxima interface even more to allow this somehow.

However, I think that in the long run, the main engine of calculus
should be in Python + Cython (maybe also in C/C++), not in LISP.
Because that will allow SAGE to extend it with new features and make
it play nicely with the rest of SAGE.

So my idea is to

3) Integrate SymPy and make it play nicely with the rest of SAGE. I
made a some progress on SD6, will send patches soon, together with a
new release of SymPy, but more work needs to be done.

Unfortunately, 3) will not solve all problems, at least not for now,
because first, there are still much more bugs in SymPy than in Maxima
(this should improve in time), and second, SymPy is slower (this could
be handled by Cython, or rewriting some parts to C/C++).

So I think the best way is to do 1), 2) and 3) in parallel and see. Is
there any other approach that I missed?

I would like to clear this out, so that I am working on something that
makes sense and is good for SAGE.

Ondrej

[mabshoff]

On Nov 15, 5:39 pm, "Ondrej Certik" <ond...@certik.cz> wrote:
> Hi,
>
> I would like to discuss how to improve calculus in SAGE.
>
> I know, that currently, most of the developers need other things more
> urgently, but I think calculus will be the most frequently used part
> in SAGE. For example all my friends and colleagues cannot really use
> SAGE at the moment, because it cannot yet compete with Mathematica in
> calculus. I would like this to be changed.
>
> Ways to progress that come to my mind:
>
> 1) Expose as much Maxima functionality as possible (one example is
> substitution of other things besides symbols).
> 2) It's important to allow users to create their own functions and the
> calculus package should be able to work with them. Maybe it will by
> possible to hack the Maxima interface even more to allow this somehow.

Yep, that sounds good to me.

>
> However, I think that in the long run, the main engine of calculus
> should be in Python + Cython (maybe also in C/C++), not in LISP.
> Because that will allow SAGE to extend it with new features and make
> it play nicely with the rest of SAGE.
>
> So my idea is to
>
> 3) Integrate SymPy and make it play nicely with the rest of SAGE. I
> made a some progress on SD6, will send patches soon, together with a
> new release of SymPy, but more work needs to be done.
>
> Unfortunately, 3) will not solve all problems, at least not for now,
> because first, there are still much more bugs in SymPy than in Maxima
> (this should improve in time), and second, SymPy is slower (this could
> be handled by Cython, or rewriting some parts to C/C++).
>
> So I think the best way is to do 1), 2) and 3) in parallel and see. Is
> there any other approach that I missed?
>

Nope, I think that using Maxima for problems that aren't efficient or
present at all in sympy id the way to go. David Harvey did mention to
me that getting a numerical approximation of sqrt(2) called maxima, so
any computation that has a bad communication to computations time
ratio should be moved to sympy quickly. On the other hand something
like solving partial differential equations where the amount of
communication via pexpect is negligible compares to the computation
itself should be lower priority. This isn't pure calculus anyway, but
I think it illustrates my point :)

> I would like to clear this out, so that I am working on something that
> makes sense and is good for SAGE.
>

Yep. It might even make it possible to ship some "Sage not so light"
version specifically targeted at the high school/educational market if
we ever decide to do such a thing.

> Ondrej

Cheers,

Michael

[Fabio Tonti]

So basically, on the long run, you would like to use SymPy together with everything rewritten in Cython? Did I get it correctly?

[Ondrej Certik]

On Nov 16, 2007 9:50 AM, Fabio Tonti <fto...@gmail.com> wrote:
> So basically, on the long run, you would like to use SymPy together with
> everything rewritten in Cython? Did I get it correctly?

Not necessarily. In the long run I want to have a very simple but fast
calculus engine, which people can easily understand and extend.

One option is to use Cython, other option is to even write it in C and
there are other options. Everything that operates nicely with Python
is an option, so LISP is out.

Ondrej

[William Stein]

On Nov 15, 2007 9:15 AM, mabshoff

<Michael...@fsmath.mathematik.uni-dortmund.de> wrote:
> > 1) Expose as much Maxima functionality as possible (one example is
> > substitution of other things besides symbols).

We've definitely laid the foundations for that step very very well.

> > 2) It's important to allow users to create their own functions and the
> > calculus package should be able to work with them. Maybe it will by
> > possible to hack the Maxima interface even more to allow this somehow.
>
> Yep, that sounds good to me.

Actually, what exactly do you mean by "users to create their own functions"?
Could you give a concrete example of what you mean by this?

> > However, I think that in the long run, the main engine of calculus
> > should be in Python + Cython (maybe also in C/C++), not in LISP.
> > Because that will allow SAGE to extend it with new features and make
> > it play nicely with the rest of SAGE.

Personally I would prefer Python + Cython more than C/C++ just for
ease of reading.

> > 3) Integrate SymPy and make it play nicely with the rest of SAGE. I
> > made a some progress on SD6, will send patches soon, together with a
> > new release of SymPy, but more work needs to be done.
>

> Nope, I think that using Maxima for problems that aren't efficient or
> present at all in sympy id the way to go.
> David Harvey did mention to
> me that getting a numerical approximation of sqrt(2) called maxima, so

That's not exactly true, since "Exiting Maxima..." is not printed out below:

sage: float(sqrt(2))
1.4142135623730951
sage: quit
Exiting SAGE (CPU time 0m0.01s, Wall time 0m5.91s).

What happens is that if one requests a numerical *float* approximation
to sqrt(2), then first a float approximation to 2 is computed, then
the math.sqrt method is called on it.

Unfortunately, evidently right now if one requests a high-precision
numerical approximation Sage currently end up calling Maxima:

sage: RealField(100) ( sqrt(2) )
1.4142135623730950488016887242
sage:
Exiting spawned Maxima process.

I consider this a mistake in implementation, which should be optimized.

Notice that

sage: sqrt( RealField(100)(2) )
1.4142135623730950488016887242

does not call Maxima anywhere.

I just investigated, and n(sqrt(2), 100) calls maxima only to simplify
sqrt(2) before even beginning to do any numerical approximation.
This isn't consistent with how the other coercions (e.g., to float)
work. So I've posted
a patch that changes this behavior:

http://trac.sagemath.org/sage_trac/ticket/1196

After applying this patch:

sage: RealField(100) ( sqrt(2) )
1.4142135623730950488016887242
sage: quit
(no "exiting maxima")

-- William

> any computation that has a bad communication to computations time
> ratio should be moved to sympy quickly. On the other hand something
> like solving partial differential equations where the amount of
> communication via pexpect is negligible compares to the computation
> itself should be lower priority. This isn't pure calculus anyway, but
> I think it illustrates my point :)
>
> > I would like to clear this out, so that I am working on something that
> > makes sense and is good for SAGE.
> >
>
> Yep. It might even make it possible to ship some "Sage not so light"
> version specifically targeted at the high school/educational market if
> we ever decide to do such a thing.
>
> > Ondrej
>
> Cheers,
>
> Michael
>
> >
>

--
William Stein
Associate Professor of Mathematics
University of Washington
http://wstein.org

[Ondrej Certik]

> > > 1) Expose as much Maxima functionality as possible (one example is
> > > substitution of other things besides symbols).
>
> We've definitely laid the foundations for that step very very well.

Yes, nice work.

> > > 2) It's important to allow users to create their own functions and the
> > > calculus package should be able to work with them. Maybe it will by
> > > possible to hack the Maxima interface even more to allow this somehow.
> >
> > Yep, that sounds good to me.
>
> Actually, what exactly do you mean by "users to create their own functions"?
> Could you give a concrete example of what you mean by this?

Yes, let's discuss some particular examples:

1) so let's say I want to extend the current default SAGE calculus
with the Order symbol. In the soon to be released SAGE, you will be
able to do:

sage: e = sin(x)
sage: taylor(e, x, 0, 6)
x - x^3/6 + x^5/120

sage: import sympy
sage: e = sympy.sin(x)
sage: e.series(x, 6)
x - 1/6*x**3 + (1/120)*x**5 + O(x**6)
sage: sympy.O(x**4)-sympy.O(x**3)
O(x**3)
sage: f = sympy.cos(x**2)
sage: print f.series(x, 2)
sage: print e.series(x, 6) * f.series(x, 2)
sage: print (e.series(x, 6) * f.series(x, 2)).expand()
1 + O(x**2)
(1 + O(x**2))*(x - 1/6*x**3 + (1/120)*x**5 + O(x**6))
x + O(x**3)

This works in SymPy, but I would like this to be working in SAGE by
default. How could I do that?

2) let's say I want to define my super new function like this:

class my_function(SingleValuedFunction):
nofargs = 1

def fdiff(self, argindex = 1):
return cos(self[0])

@classmethod
def canonize(cls, arg):
arg = sympify(arg)
if arg == 0:
return sympify(0)

and then I want to call

my_function.series(x, 6)

and it will return the same series as for sin, because you notice that
my_function is a disguised sin (the same derivative, the same function
value at x=0).

Then let's say I would like to know the limit

limit(my_function(x) / x, x=0)

and it should just work. This is possible in SymPy (ok, technically
right now, it's a little more complex in SymPy, but we are going to
simplify it), but how could I do this
with the maxima interface?

After talking at SD6, maybe it could be possible to do it by creating
some maxima code behind the scene, so that maxima is able to calculate
with my new function.

>
> > > However, I think that in the long run, the main engine of calculus
> > > should be in Python + Cython (maybe also in C/C++), not in LISP.
> > > Because that will allow SAGE to extend it with new features and make
> > > it play nicely with the rest of SAGE.
>
> Personally I would prefer Python + Cython more than C/C++ just for
> ease of reading.

Yes, me too, Cython is awesome. If together with Cython, we could
speed SymPy up to the speed of Maxima, that's the way to go.
If not, we would have to thing harder.

Ondrej