Compatibility with DifferentialEquations.jl

Right now, this package is not compatible with the RecursiveArrayTools.jl package used by DifferentialEquations.jl.

e.g. here is a simple example from the DifferentialEquations tutorial, modified to use a TupleVec(dx, [dy, dz]) of a scalar and a vector:

using DifferentialEquations, TupleVectorSpaces

function lorenz(u, p, t)
    dx, (dy, dz) = Tuple(u)
    dx = 10.0 * (u[2] - u[1])
    dy = u[1] * (28.0 - u[3]) - u[2]
    dz = u[1] * u[2] - (8 / 3) * u[3]
    TupleVec(dx, [dy, dz])
end

u0 = TupleVec(1.0, [0.0, 0.0])
tspan = (0.0, 100.0)
prob = ODEProblem(lorenz, u0, tspan)
solve(prob, Tsit5());

This gives the error:

MethodError: no method matching ndims(::Type{TupleVec{Tuple{Float64, Vector{Float64}}}})
The function `ndims` exists, but no method is defined for this combination of argument types.

Closest candidates are:
  ndims(::Type{Union{}}, Any...)
   @ Base abstractarray.jl:276
  ndims(::Type{<:AbstractVectorOfArray{T, N}}) where {T, N}
   @ RecursiveArrayTools ~/.julia/packages/RecursiveArrayTools/Y3i0V/src/vector_of_array.jl:595

Although it would technically be possible to support indexing into a TupleVec, i.e. to make it act like an AbstractVector, I'd really rather keep it more general and represent an element of an arbitrary normed vector space. I don't see any fundamental technical reason why this shouldn't be compatible with numerical ODE solvers (just as it's already compatible with numerical integration).

@ChrisRackauckas, is there a way to tell RecursiveArrayTools not to try to "look inside" a TupleVec, and instead treat it as an opaque mathematical object? As long as we're not trying to work in-place, at least for explicit solvers I don't see why you should need to look inside the vector.

Inizia riproducendo l’esempio di Lorenz di DifferentialEquations.jl con TupleVectorSpaces e l’errore ndims segnalato di RecursiveArrayTools. Esamina come RecursiveArrayTools gestisce TupleVec e come il package rappresenta spazi vettoriali normati arbitrari; il lavoro è completato quando l’esempio del solver esplicito viene eseguito senza richiedere che TupleVec si comporti come un AbstractVector.