f=solve(ode)
giving an interpolable object with call overloaded so that f(t)
=> y(t)
and f'(t)
=> dy(t)
. And with getindex
defined so that f[i]
=>y[i]
or f[i]
=>(t[i],y[i],dy[i])
.
yout(f)
returning your Matrix
or whatnot
Yes, you're right, changing the return type depending on a keyword argument is bad.
Concerning your example, yes, there can be corner cases. The beauty of building on iterators, is that one can always drop down to them and do what one wants. Alternatively, we could only return a matrix when isa(y0, Vector)
, that should cover 95% of the use-cases.
When the number of output points is not known, then make a vector, push to that and reshape in the end. (Note that the reshape does not copy but just re-interprets the memory as matrix).
I still don't want to call something a solution which is not a solution at all but can only be used to, maybe, generate a solution.
( sqrt(sum(squares)/length))
can be more efficient.
LoadError: LoadError: LoadError: type Array has no field x
in anonymous at /home/travis/.julia/v0.4/ODE/src/tests/test_cases.jl:68
in call at /home/travis/.julia/v0.4/ODE/src/base.jl:84
in include at ./boot.jl:261
in include_from_node1 at ./loading.jl:320
in include at ./boot.jl:261
in include_from_node1 at ./loading.jl:320
in require at ./loading.jl:259
in eval at /home/travis/.julia/v0.4/DifferentialEquations/src/DifferentialEquations.jl:3
in init_package at /home/travis/.julia/v0.4/DifferentialEquations/src/general/backends.jl:23
in init_package at /home/travis/.julia/v0.4/DifferentialEquations/src/general/backends.jl:16
in initialize_backend at /home/travis/.julia/v0.4/DifferentialEquations/src/general/backends.jl:5
in solve at /home/travis/.julia/v0.4/DifferentialEquations/src/ode/ode_solve.jl:230