On Wed, 2016-06-08 at 18:50, Gabriel Gellner <gabrielgell...@gmail.com> wrote: > 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 ;)
I'm pretty sure this will change pretty soon. I think it's in @pwl's big PR. The rational for the current way is that in the call tout, yout = ode(f, y0, tspan) y0 needn't be an array but any object which supports the needed math. So yout couldn't be an Array{N,2} in the general case. But of course, most of the time y0 will be a Vector and then typeof(yout)==Array{N,2} would make the most sense. The current behavior of returning a Vector{Vector} is far too annoying, so it has to change, I think. > > > > > 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. I think once you get this far, then you should just use the lower level API, which will not be very complicated either. > 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. Yes, the high-level API may well evolve to use something like solver objects. Maybe: ode(rk45, f, y0, tspan) Yes, Distributions.jl is nice indeed. I'll look at their API a bit more closely. Thanks for your feedback!