6 views

Skip to first unread message

Nov 15, 2007, 11:39:48 AM11/15/07

to sage-...@googlegroups.com

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

Nov 15, 2007, 12:15:03 PM11/15/07

to sage-devel

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.

>

> 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?

>

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.

>

version specifically targeted at the high school/educational market if

we ever decide to do such a thing.

> Ondrej

Cheers,

Michael

Nov 16, 2007, 3:50:10 AM11/16/07

to sage-...@googlegroups.com

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

Nov 16, 2007, 9:53:21 AM11/16/07

to sage-...@googlegroups.com

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?

> 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

Nov 17, 2007, 11:15:58 PM11/17/07

to sage-...@googlegroups.com

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).

<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

Nov 18, 2007, 5:10:41 AM11/18/07

to sage-...@googlegroups.com

> > > 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.

> > > 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

Reply all

Reply to author

Forward

0 new messages

Search

Clear search

Close search

Google apps

Main menu