Hi Alex, I do have a GitHub account, and I'll post my ideas over there. Here are my thoughts :
- The solver need to be fast and for that, inlining is of paramount importance. I know that there is no way to inline F for the time being. Do we expect inlining on function argument in the near future of Julia ? - It might be nice to have the general case : y^(n)(t) = F(t, y, y'(t), ... , y^(n-1)(t)). Even though nth-order equation can be reduced to first order equation, I've heard that some specific methods exists for n-th order equation. I need to check on this. - I think that the options need to be more organized. I like how it is handled in the GSL. Basically, there are 2 main options : - How do you go from t, to t + dt : Euler, Explicit Runge-Kutta, etc... - How do you choose dt : Given by tspan, computed for a tolerance, .... Gving 2 identified objects is a nice way to stress that. François On Friday, May 16, 2014 11:26:21 PM UTC+2, Alex wrote: > > Hi François, > > Nice to hear that you are interested in contributing to ODE.jl. Any input > is greatly appreciated! I guess you have also seen some of the open issues > discussing the API over at ODE.jl, so if you have a github account it might > be good to post your thoughts there as well. > > Regarding the API I think we roughly came to the following consensus: > - there should be a "simple" API with solvers like you said, odeX(F, y0, > tspan; kwargs), where odeX denotes the method (say ode45 for an explicit > Runge-Kutta method using pair 4-5), F is the rhs of the ODE, tspan gives a > integration interval and kwargs are keywords like tolerances etc. > - for more sophisticated control we will have an abstract type ODEProblem > from which more specific problems, like ExplicitODE or ImplicitODE, can be > derived and which will allow for providing additional information like > Jacobians and so on. The method will probably still be selected by the > function name and by using multiple dispatch the methods can "choose" which > problems they support. > > I should add that most of this (maybe the second part more than the first > one) is still under debate and we are open for any suggestions. > > Best, > > Alex. > > > > > Hi, > > > > > > I am starting to use Julia, and I would like to learn and contribute a > bit. As I have some experience in numerics I am thinking of contributing to > the ODE package. > > > > > > I've read the ideas for the API, and I believe that we can still improve > it. Usually, for this kind of solver, we could expect something such as : > > > > > > ode_solve( F, y_0, t_0:t_1; stepping_method; step_choice_method ) > > > > > > where the stepping_method could be : > > - Explicit Runge-Kutta > > It is is that kind of method, we also need some parameters such as the > order of the method > > - other methods ... > > > > > > So how would you organise that ?My idea would be choosing SteppingMethod > as an abstract type, and ExplicitRungeKutta as a concrete subtype that has > different parameters. What do you think of that ? Is there a standard way > to pass options to a function ? > > > > > > I was thinking at looking at Gadfly to see how options are handled here. > Do you recommend another package worth checking ? > > > > > > Best regards, > > François >
