# Why can't we resize a reinterpreted matrix?

We can resize a vector of static arrays:

``````julia> v = [ rand(SVector{3,Float64}) for _ in 1:2 ];

julia> resize!(v, 3)
3-element Vector{SVector{3, Float64}}:
[0.49021421932808495, 0.04375803657360211, 0.6957281082155673]
[0.08420472085130659, 0.6281088019727706, 0.004126731413303553]
[0.0, 0.0, 0.0]

``````

AFAIU, a (3,N) matrix has the same memory layout, thus, effectively, we can reinterpret such a matrix as a vector of SVectors:

``````julia> x = rand(3,2)
3×2 Matrix{Float64}:
0.948469   0.260338
0.773314   0.616487
0.0618051  0.279425

julia> y = reinterpret(reshape, SVector{3,Float64}, x)
2-element reinterpret(reshape, SVector{3, Float64}, ::Matrix{Float64}) with eltype SVector{3, Float64}:
[0.948469068098922, 0.7733139138943798, 0.06180507432707616]
[0.2603384894132955, 0.6164869874966521, 0.2794245241939306]

``````

Why can’t we `resize!` that resulting reinterpreted vector of SVectors? (or, similary, why can’t we add or remove columns from a matrix?). Or, if there is intrinsic reasons for that not being possible, why can we `resize!` the vector of SVectors in the first place?

I asked a similar question some time ago, see resize! for multidimensional arrays · Issue #37900 · JuliaLang/julia · GitHub

2 Likes

Even if the parent array were a `Vector`, you couldn’t resize the `reinterpret`ed array. `reinterpret` made a `Base.ReinterpretArray`, a wrapper struct with a `.parent` field referencing the parent array, so it doesn’t actually own its data. If you want to resize it, you have to change the parent array in 1 of 2 unsavory ways:

1. Resize the parent array implicitly, and I can’t justify mutating any instance implicitly.
2. Append data to the underlying buffer just for the `ReinterpretArray`, but now you have to disallow resizing the parent array or else you would corrupt the data belonging to the `ReinterpretArray`.

That’s not to say that you’re restricted from doing all unsafe things with shared buffers; you can mutate the parent array in ways that changes the wrappers. It’s just in this case your parent array is not 1-dimensional, so you can’t resize it. The linked github issue in the last comment ended on a question I really want answered, though; I had always assumed they drew the resizability line at vectors because appending data for N-1 dimensions along 1 specific dimension would be too large and inflexible a behavior, but it reads like there’s a whole other dimension to the issue.

2 Likes

Effectively, that would answer it all.