[sage-devel] Re: Fwd: ode_solver
Perhaps this could be written to use the new rdef function code, to make it easier for the user to provide a cdef function to the solver. That would be great. As a short term alternative, I think I will write my own simple 4th-order Runge-Kutta solver in cython, but it would be nice to be able to exploit the GSL fully. -Marshall --~--~-~--~~~---~--~~ 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/ -~--~~~~--~~--~--~---
[sage-devel] Re: Fwd: ode_solver
On Oct 14, 2007, at 1:40 AM, Joshua Kantor wrote: 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. Perhaps this could be written to use the new rdef function code, to make it easier for the user to provide a cdef function to the solver. - Robert --~--~-~--~~~---~--~~ 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/ -~--~~~~--~~--~--~---
[sage-devel] Re: Fwd: ode_solver
Is rdef in sage 2.8.7? David On 10/16/07, Robert Bradshaw [EMAIL PROTECTED] wrote: On Oct 14, 2007, at 1:40 AM, Joshua Kantor wrote: 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. Perhaps this could be written to use the new rdef function code, to make it easier for the user to provide a cdef function to the solver. - Robert --~--~-~--~~~---~--~~ 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/ -~--~~~~--~~--~--~---
[sage-devel] Re: Fwd: ode_solver
Yep, that was the main (in my opinion for SAGE) feature enhancement of cython 0.6.7 (included in sage 2.8.7). I am still not sold that rdef is the best name, been toying with bdef (for both) or something else, but we can start using it and if the signature changes, that's a one-line patch. - Robert On Oct 16, 2007, at 1:28 PM, David Roe wrote: Is rdef in sage 2.8.7? David On 10/16/07, Robert Bradshaw [EMAIL PROTECTED] wrote: On Oct 14, 2007, at 1:40 AM, Joshua Kantor wrote: 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. Perhaps this could be written to use the new rdef function code, to make it easier for the user to provide a cdef function to the solver. - Robert --~--~-~--~~~---~--~~ 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/ -~--~~~~--~~--~--~---
[sage-devel] Re: Fwd: ode_solver
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,
