new talk: The Development of Symbolic Calculus in Sage
William Stein
--
William Stein
Professor of Mathematics
University of Washington
http://wstein.org
Martin Rubey
> http://wstein.org/talks/stein-sd24/stein-sd24.pdf
"world domination" has a very intimidating (naziesque) connotation for
me (I do not think only for me, but I cannot know). Sage is great, but
that makes me shiver.
Martin
Dr. David Kirkby
> http://wstein.org/talks/stein-sd24/stein-sd24.pdf
>
Point #7 about why you don't like Magma may be true. The developer community
might be too small, and there may be no public mailing list.
But to say the same is true of Maple - "(Similar remarks about Maple)", is IMHO
untrue. There are a lot of Maple users. There is the newsgroup
comp.soft-sys.math.maple. Maple questions are often asked (and answered) on
sci.math.symbolic.
http://shell.cas.usf.edu/~wclark/maple_links.html
lists more Maple resources.
For a viable alternative you list:
"All the mathematical features of Magma, Maple, Mathematica, and Matlab with
comparable (or better) speed, including sophisticated symbolic calculus, special
functions, global fields, easy of use and documentation."
Can you make an estimate, based on extrapolating the progress of Sage, when it
would be possible to have this, based on the state of these products in 2010?
(Ignore future developments of these products). Do you think it will be possible
in your lifetime?
PS, One thing you omitted from that list, is being no less reliable than any of
them.
Dave
William Stein
<david....@onetel.net> wrote:
> On 07/17/10 07:50 AM, William Stein wrote:
>>
>> http://wstein.org/talks/stein-sd24/stein-sd24.pdf
>>
>
> Point #7 about why you don't like Magma may be true. The developer community
> might be too small, and there may be no public mailing list.
>
> But to say the same is true of Maple - "(Similar remarks about Maple)", is
> IMHO untrue.
Similar != Same.
> There are a lot of Maple users. There is the newsgroup
> comp.soft-sys.math.maple. Maple questions are often asked (and answered) on
> sci.math.symbolic.
>
> http://shell.cas.usf.edu/~wclark/maple_links.html
>
> lists more Maple resources.
>
> For a viable alternative you list:
> "All the mathematical features of Magma, Maple, Mathematica, and Matlab with
> comparable (or better) speed, including sophisticated symbolic calculus,
> special functions, global fields, easy of use and documentation."
>
> Can you make an estimate, based on extrapolating the progress of Sage, when
> it would be possible to have this, based on the state of these products in
> 2010? (Ignore future developments of these products).
No.
> Do you think it will
> be possible in your lifetime?
>
> PS, One thing you omitted from that list, is being no less reliable than any
> of them.
>
> Dave
>
> --
> To post to this group, send an email to sage-...@googlegroups.com
> To unsubscribe from this group, send an email to
> sage-devel+...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/sage-devel
> URL: http://www.sagemath.org
Thierry Dumont
Reading this document, I was, among many things, very interested by the
2012 horizon (Sage 7.0) and specially by the Engineering projects.
I am interested by this point and would like to contribute, if possible.
My remarks and questions:
*During the long time I spent with P. Zimmermann and others writing our
book, I tested a large part of the numerical methods. Some things are
lacking, others cannot actually be used, and do not provide an
alternative to Mat*b. But all this can be improved, and the Python basis
is very nice.
Examples:
1) linear algebra: the support for sparse matrices cannot be used in
real problems: we want to solve large (say 10^5) systems of equations.
The lil_matrix class of Scipy is so slow, that it is a pity.
2) ODEs: the support provided by scipy is very basic, and insufficient
at least for me. Everything is too old!
I have mostly looked at these points.
*Question: will (most of) Sage numerical methods remain based on Scipy?
*How I think we can improve points 1) and 2):
1) sparse matrices are created using lil_matrix, based on dictionaries.
I personally use (out of Sage) a C++ class based on std::map which
performs some orders faster. It could be integrated either directly in
Sage, or in Scipy.
2) For the ODEs, the best and the most *modern* methods are there:
http://www.unige.ch/~hairer/software.html
H. Hairer, G. Wanner, C. Lubich are among the best specialist of
numerical methods for ODE and their programs (even if written in f77)
are wonderful, and very robust and efficient. Writing an interface may
not be a so large task (there is already a Matlab interface) and we
would have the best for stiff systems, Hamiltonian systems (make
celestial mechanics with Sage) and so on... This would be in the spirit
of Sage, I think: use the best software available, written by true
specialists.
But may be there are already projects (for point 2)) ? let me know...
Thierry Dumont.
John Cremona
since I have one too (and it is in Sage in the eclib spkg). If you
type CremonaModularSymbols(12345) they are being used.
John
On 17 July 2010 10:03, Thierry Dumont <tdu...@math.univ-lyon1.fr> wrote:
Harald Schilly
On Jul 17, 11:03 am, Thierry Dumont <tdum...@math.univ-lyon1.fr>
wrote:
> 2) For the ODEs, ... (even if written in f77)...
I don't know their work but I think there is nothing wrong with f77
for this type of problem. Do you know f2py [1]? Shouldn't be too hard
to wrap their f77 functions in python!
[1] http://cens.ioc.ee/projects/f2py2e/
H
Thierry Dumont
also, lapack, which is pure f77 code is wrapped in Scipy... so it should
not be difficult at all.
My main question is whether there is an other project concerning EDOs
and Sage. If not, I can start coding.
T.D.
Francesco Biscani
<tdu...@math.univ-lyon1.fr> wrote:
> 2) For the ODEs, the best and the most *modern* methods are there:
> http://www.unige.ch/~hairer/software.html
> H. Hairer, G. Wanner, C. Lubich are among the best specialist of numerical
> methods for ODE and their programs (even if written in f77) are wonderful,
> and very robust and efficient. Writing an interface may not be a so large
> task (there is already a Matlab interface) and we would have the best for
> stiff systems, Hamiltonian systems (make celestial mechanics with Sage) and
> so on... This would be in the spirit of Sage, I think: use the best software
> available, written by true specialists.
Nice pointer, did not know about that page :)
Another interesting approach for ODE that I did not see mentioned is
that of Taylor integrators, e.g.:
http://www.maia.ub.es/~angel/taylor/
It should not bee to hard to wrap in Python using Weave and
translating symbolic expressions into the text format used by the
integrator.
Cheers,
Francesco.