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!
