I absolutely agree in general. I am terrified when julia code gets to fancy :) I am largely a bear of little brain... (thos ODE.jl choice to send back array of arrays kind of breaks this feeling for simplicity ... having to learn to do hcat(sol...)' for the common case, versus letting this work for some high dimensional vector field case that was discussed feels like leaning on the side of complex ;)
> > > sol = dsolve(RK54(func, y0), trange, <solver options>) > > maybe better: > > sol = dsolve(func, y0, trange, RK54(<solver options>) ) > > > This would more follow the way that Optim.jl has gone (sort of they seem to separate some of the general solver options, from the specific options. I haven't followed enough to know why this separation was desired). The problem I see with this is that it overly relies on separating the func and array from the model/problem type. So again you suffer from not being able to do the easy to understand (and for larger problems likely more efficient as you don't have to reallocate the temp arrays, but the naive user need not understand this). prob = RK45(func, y0) sol = dsolve(prob, tspan, <solver options>) sol2 = dsolve(prob, tspan2, <solver options>) as likely you will need to know the dimension of y0 to allocate all the underlying solver work space arrays, so RK45(<solver options>) can not be entirely decoupled from the "model" definition. > Well, either is fine. I think it is important that the high-level > interface is free or mostly free from custom types. A casual user > shouldn't need to learn about special types and be able to just use > arrays and functions. (I find that with Julia's awesome type system it > is easy to overdo it on the types.) > > I guess the key I see is that the matlab way of doing things encodes the "type" of the solver into the name of the function "ode45, ode23" etc whereas if you have a wrapper type (or some function that returns such a type) then you just do desolve(solver_type, ...) which doesn't feel in any way more complex. The end user need not know anything about the type if they don't want to, they just need to know if you want the ode45 like behavior your do desolve(RK45(func, y0), tspan) vs ode45(func, y0, tspan) hell if the length is an issue you could have ode(RK45(func, y0), tspan) for only an extra 3 characters ;) with the super nice behavior of not having an entirely different api for when you need finer control (you just need extra knowledge of the special types). That is why I feel that following the matlab way of doing things so closely (ie requiring a pure array + callback version) limits the api without making it simpler for the end, naive, user. I guess I see the above way as being no different that using something like Distributions.jl, which I see as one of the nicest uses of types from an api perspective. Getting to do rand(disttype, options) is super easy to understand versus having a billion specialty functions that take the raw options and dist parameters. Just my thoughts as an end user. Those that are working on this will decide, but I feel the distaste for types in this simple case feels overly pessimistic.
