On Nov 15, 5:39 pm, "Ondrej Certik" <[EMAIL PROTECTED]> 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
--~--~---------~--~----~------------~-------~--~----~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/
-~----------~----~----~----~------~----~------~--~---
