collect_transpose, or whatever you call it, is essentially an extremely simple wrapper around an iterator. It's still far from something that a name
collect_transposeas to how to accumulate the output
collect_transposeis the right name for the function we need but it's closer to what it actually does then
as for the output, let's say I have a custom type to hold points:
type Point<:AbstractVector x;y end getindex(::Point)=...
there is no way you can push it into a
Matrix without loosing its interpretation as a point.
Moreover, how do you imagine handling the matrix if you don't know it's size a priori? The only way you will know the size is to run the iteration, but then you still have to store the output at the same time. But if you are already storing the output (as a vector) then you would only loose on performance if you want to convert it in afterward (e.g. to a matrix).
f=solve(ode)giving an interpolable object with call overloaded so that
dy(t). And with
getindexdefined so that
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.