Good to see that you got things sped up. The factor of 30 or so slowdown is consistent with my experience comparing to matlab. I believe the issue is that due to the way the interface to gsl works
explanation: The gsl ode solver is a c function that requires a C function pointer to be passed to it. So we have to convert the users python function into a C function, this is done by defining a cdef pyrex function that takes the users function as an argument and calls it. So in the end every function evaluation calls a C function which calls your python function. Python function calls are expensive so this adds overhead. It is possible to directly define the system as a pyrex object which makes the wrapping unnecessary and means all function calls are in C, this is much faster and I found it to be comparable to matlab, however, this is hard for a general user to do. Josh On Oct 11, 8:08 am, Marshall Hampton <[EMAIL PROTECTED]> wrote: > ---------- Forwarded message ---------- > From: Marshall Hampton <[EMAIL PROTECTED]> > Date: Oct 10, 12:07 pm > Subject: ode_solver > To: sage-support > > I have used cython to try to speed up my function evaluations. The > computation that used to take about 2400 seconds (40 minutes) now > takes 38 seconds - a very nice improvement. I can more or less live > with that, although as I noted before mathematica takes about 1.5 > seconds, and its solution looks quite accurate. So we can do better. > Josh Kantor has suggested that I try the scipy integrate command, > which I hope to do soon. Maybe it will be faster. > > To fix the interpolation problems, I just use the line command: > > T = ode_solver() > # lots of stuff I am leaving out > t_data = T.solution > show(line([[x[0],x[1][2]] for x in tdata]) > > In case anyone is interested in the full details, I have put a text > file with a minimal version of my model up at: > > http://www.d.umn.edu/~mhampton/Model1.txt > > Marshall > > On Oct 5, 10:14 am, "William Stein" <[EMAIL PROTECTED]> wrote: > > > On 10/5/07, David Joyner <[EMAIL PROTECTED]> wrote: > > > > I think this was written by Josh Kantor, but possibly it was > > > William Stein. > > > > I don't understand it either. Sorry. > > > Josh wrote it. It wraps gsl. You might be defining a function whose > > evaluation is really slow, e.g., if it involves symbolic calculus in > > any way, it could be very slow, and that would slow down everything > > else. So you might: > > (1) make sure any functions involved evaluate very very quickly. > > (2) consider using scipy's ode solving capabilities, which are quite > > fast. > > (3) wait for Josh to make some helpful remarks -- but only expect that > > if you post complete details about what you're doing. > > > William > > > > On 10/5/07, Hamptonio <[EMAIL PROTECTED]> wrote: > > > > I just moved an ODE model of mine over to sage from mathematica and I > > > > am trying to use ode_solver to deal with it. Now that I am using it > > > > seriously I found a few issues. I am happy to try to help solve them > > > > but I don't know the code well yet. > > > > > 1) Trivial documentation error: in "runge-kutta-felhberg", fehlberg is > > > > misspelled. > > > > 2) interpolate_solution acts a little funny. I was using a 5000 point > > > > solution, and the interpolation seemed to be ignoring some points - > > > > i.e. perhaps it only uses a sample of the solution? I have a rapidly > > > > oscillating solution, and the interpolation fails pretty badly. > > > > 3) It is extremely slow. I have a rather complicated system of three > > > > variables. Mathematica's NDSolve takes about 1.5 seconds to solve it > > > > on one computer, and ode_solver takes about 2400 seconds on a better > > > > computer. I will have to learn more pyrex I guess. I was surprised > > > > by how bad the difference was. > > > > > Marshall > > > > > On Apr 1, 8:04 pm, "David Joyner" <[EMAIL PROTECTED]> wrote: > > > > > On 1/4/07, JoshuaKantor<[EMAIL PROTECTED]> wrote: > > > > > > > In response to Williams sage-2.0 plan I wanted to describe what I > > > > > > had done > > > > > > with using gsl to implement a numerical ode solver. I believe that > > > > > > the > > > > > > patch containing this will be applied after > > > > > > doing a recent pull or upgrade but I'm not sure(is this true?). If > > > > > > not > > > > > > ...... > > > > > > Ideas for extension: > > > > > > > 1. It would be nice if there was some facility for automatically > > > > > > converting a nth order ODE > > > > > > to a system of first order ones. > > > > > > If an n-th order ODE is simply a function of the variables > > > > > x, y0=y, y1=y',...,yn = y^(n), then this is easy to write. > > > > > Should the n-th order ODEs form a class? > > > > > > > 2. It would be nice if there was some facility for automatically > > > > > > computing > > > > > > the jacobian when the functions involved are rational functions and > > > > > > elementary functions. > > > > > > Maxima has a function called hessian, as well as > > > > > a determinant. Together, I think they should do > > > > > what you want. > > > > > > > 3. Numerically computing the jacobian: For the algorithms that > > > > > > require the > > > > > > jacobian It would be possible to numerically compute the jacobian, > > > > > > however I was wary of doing this by default. Does anyone have any > > > > > > knowledge > > > > > > about > > > > > > the benefits of this, can it cause instability (using the numerical > > > > > > jacobian > > > > > > instead of the exact one). > > > > > > I don't but I agree with you anyway. > > > -- > > William Stein > > Associate Professor of Mathematics > > University of Washingtonhttp://wstein.org --~--~---------~--~----~------------~-------~--~----~ 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/ -~----------~----~----~----~------~----~------~--~---
