RecursiveArrayTools.jl
RecursiveArrayTools.jl copied to clipboard
Vector of differently sized arrays
julia> size(VectorOfArray([randn(2), randn(4)]))
(2, 2)
This is surprising at least, and runs the risk of subtle bugs if one tries to iterate on the VectorOfArray as if it was a multi-dimensional array.
This is something we need and use in DiffEq for models which dynamically change over time.
Oh I need it too and was pleasantly surprised to see that it worked. The thing is the size
method: should it be undefined, or perhaps check that the sizes are all equal at runtime?
Yeah... I don't know. It's something I've never figured out. size
is useful in a lot of cases, but when you have a ragged array it's wrong. Maybe it's worth doing a runtime check.
size is useful in a lot of cases
Thought so too but probably it's a code smell for generic code that doesn't assume much about array types. It's only really good for plain old arrays
Yes, is used when doing conversions like Array(x)
, but there are issues with it we haven't solved.
julia> vec(VectorOfArray([rand(3), rand(5)]))
ERROR: ArgumentError: number of rows of each array must match (got [3, 5])
Stacktrace:
[1] _typed_hcat(#unused#::Type{Float64}, A::Vector{Vector{Float64}})
@ Base ./abstractarray.jl:1518
[2] reduce(#unused#::typeof(hcat), A::Vector{Vector{Float64}})
@ Base ./abstractarray.jl:1572
[3] Array
@ ~/.julia/dev/RecursiveArrayTools/src/vector_of_array.jl:11 [inlined]
[4] convert
@ ./array.jl:532 [inlined]
[5] vec(VA::VectorOfArray{Float64, 2, Vector{Vector{Float64}}})
@ RecursiveArrayTools ~/.julia/dev/RecursiveArrayTools/src/vector_of_array.jl:120
[6] top-level scope
@ REPL[11]:1
This can be triggered e.g. when solving a SteadyStateProblem