Its probably a good time to see what we can do to improve the way sage
handles ordinary differential equations. I would vote against making
improvements directly to maxima, and instead think about how we can
implement our own de solvers, perhaps using sympy, or using regular
expression matching to an internal de representation. Here are some
random comments:
1) The sage interface to maxima does not use contrib_ode=True by
default, which severely limits maxima's ability to solve common ODEs
sage: f=function('f',x)
sage: desolve(f.diff(x,2)-x*f,f)
---------------------------------------------------------------------------
NotImplementedError Traceback (most recent call
last)
/home/jlh/<ipython console> in <module>()
/home/jlh/wrk/sage-5.0.beta11/local/lib/python2.7/site-packages/sage/
calculus/desolvers.pyc in desolve(de, dvar, ics, ivar, show_method,
contrib_ode)
445 raise NotImplementedError, "Maxima was unable
to solve this ODE."
446 else:
--> 447 raise NotImplementedError, "Maxima was unable to
solve this ODE. Consider to set option contrib_ode to True."
448
449 if show_method:
NotImplementedError: Maxima was unable to solve this ODE. Consider to
set option contrib_ode to True.
sage: desolve(f.diff(x,2)-x*f,f,contrib_ode=True)
[f(x) == k1*sqrt(-x)*bessel_j(1/3, -2/3*sqrt(-x)*x) + k2*sqrt(-
x)*bessel_y(1/3, -2/3*sqrt(-x)*x)]
That could have been returned as an Airy function, but the above is
still correct. Unfortunately, sympy does not even implement the
bessel differential equation, x*x*diff(f,x,2) + x*diff(f,x,1) + x*x*f,
so there's not much help there. Perhaps we should use
contrib_ode=True by default?
2) Many useful external packages that sage could employ, like those
listed here: http://www.warrenweckesser.net/vfgen/index.html, require
ODEs to be represented as equations for vector fields, i.e., reduced
to a system of first order equations. Such algorithms are
straightforward, and usually taught in any undergraduate ODE class,
but AFAICT such an algorithm is present in not implemented in either
maxima or sage or sympy. Maple includes the command convertsys:
http://www.maplesoft.com/support/help/Maple/view.aspx?path=DEtools/convertsys
and there is this single email on the maxima mailing list,
http://www.math.utexas.edu/pipermail/maxima/2006/001376.html, but it
looks like it was never implemented.
3) We should decide how to represent ODEs in sage with a mind towards
lookup table solutions. I like the current D[ ] notation like this:
x^2*D[0, 0](f)(x) + (x^2 - 9)*f(x) + x*D[0](f)(x) , which we can
access for now as 'str(de)' since we can't internally parse ODEs to
get the coefficients. Once the coeffs are parsed, we can apply the
usual simplify and test (is_polynomial, is_constant) and apply
maxima's algorithm in python. Even if we only catch most or some of
the formulas this way and have to punt to maxima for the rest, we'll
at least have a good start towards migrating fully to a python-only
solution.
Thoughts?
John Hoebing
--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to
sage-devel+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org
