How to generate independent vectors via for-loop?

General Usage
1

At a point in my real code, I want to generate a number of independent vectors based on parameter N(which is calculated at a certain point in the code). For example, if N=3, then I need to generate the following vectors:

vector_1 = [0,0];
vector_2 = [0,0,0];
vector_3 = [0,0,0,0];

So, I tried to write something like below. However, there are two problems:
1- Syntax of vector_"$i" gives error . How to write the correct syntax?
2- Assuming the syntax is correct, an error is given at S = vector_"$i" since the vectors are not seen out of the for-loop scope. How to make the generated vectors seen out of for-loop scope?

function dd()
N =3;
for i = 1:N
    vector_"$i" = zeros(i+1); # gives `ERROR: UndefVarError: @vector__str not defined`
end
S = vector_1; # gives `ERROR: UndefVarError: vector_1 not defined`
end
dd()
2

Store these vectors in a dictionary. Don’t try to make them variables.

function dd()
    N = 3
    out Dict()
    for i = 1:N
        out[i] = zeros(i + 1)
    end
    return out
end

vector_dict = dd()
3

or a vector of vectors

julia> vectors = Vector{Int}[]
       for i in 1:3
           push!(vectors, zeros(i))
       end

julia> vectors
3-element Vector{Vector{Int64}}:
 [0]
 [0, 0]
 [0, 0, 0]

(also I would recommend typing the Dict, if the case Dict{Int,Vector{Int}}(():

julia> d = Dict{Int,Vector{Int}}()
Dict{Int64, Vector{Int64}}()

julia> for i in 1:3
           d[i] = zeros(i)
       end

julia> d
Dict{Int64, Vector{Int64}} with 3 entries:
  2 => [0, 0]
  3 => [0, 0, 0]
  1 => [0]
4

Or even as a tuple

julia> ntuple(i->zeros(i+1), 3)
([0.0, 0.0], [0.0, 0.0, 0.0], [0.0, 0.0, 0.0, 0.0])

You can dynamically generate variables using eval, but they will necessarily live in global scope. Don’t do it. Seriously. It leads to hard to read and reason about code, and a cluttered global namespace. Nevertheless:

julia> for i = 1:N
           var = Symbol("vector_$i")
           eval( :( $var = zeros($i+1) ));
       end

julia> vector_1
2-element Vector{Float64}:
 0.0
 0.0

julia> vector_2
3-element Vector{Float64}:
 0.0
 0.0
 0.0
5

Thanks for your comment. The issue here is that I need to connect the generated vectors to other ones (which are changing in time-domain loop. For example, vectors[2] = @view(D[:]). However, a change in D will not be updated in vectors[2]/

D = [55,69];
vectors = Vector{Int}[]
       for i in 1:3
           push!(vectors, zeros(i))
       end

vectors[2] = @view(D[:]);
D[1] = 77;
julia> vectors
3-element Vector{Vector{Int64}}:
 [0]
 [55, 69]
 [0, 0, 0]
6

Thank you very much for your note. Can I restrict the generated vectors to be ONLY in scope of dd() function?

function dd()
N=3
for i = 1:N
    var = Symbol("vector_$i")
    eval( :( $var = zeros($i+1) ));
end
end

dd()
7

That’s because vectors is of type Vector{Vector{Int}} whereas @view(D[:]) is a subarray. Upon assignment vector[2] = @view(D[:]) a conversion to the former type, i.e. an implicit copy is made.
You could widen the container type

julia> vectors = AbstractVector{Int}[]

julia> for i in 1:3
           push!(vectors, zeros(i))
       end

julia> vectors
3-element Vector{AbstractVector{Int64}}:
 [0]
 [0, 0]
 [0, 0, 0]

julia> vectors[2] = @view(D[:]);

julia> vectors
3-element Vector{AbstractVector{Int64}}:
 [0]
 [55, 69]
 [0, 0, 0]

julia> vectors[2]
2-element view(::Vector{Int64}, :) with eltype Int64:
 55
 69

julia> D[1] = 77
77

julia> vectors
3-element Vector{AbstractVector{Int64}}:
 [0]
 [77, 69]
 [0, 0, 0]
8

No, that’s what I stated. eval evaluates an expression in the global scope of the module.

9

IMHO this should just error.

10

Thank you very much!
From a performance point of view, Do the values of vectors[2] are allocated in order in memory (column-major)? In other words, do working on the vector vector_2 is the same as on vectors[2]?

vector_1 = [0,0];
vector_2 = [0,0,0];
vector_3 = [0,0,0,0];
11

Performance-wise this will be quite bad in general, because you are handling a container with an abstract type.

If you need performance there you probably want something else, and this becomes a xy problem.

12

Yes, they form a concrete vector. Accessing vectors[2] is bad performance-wise because of the abstract container type. If you can live with that depends on the kind of work and how much indexing is done. Using a function barrier might be sufficient to make the overhead from the type instability due to indexing into vectors negligible.

13

Another option if you know how many you want at compile time:

sizes = (2,3,4)
Base.Cartesian.@nexprs 3 j->vector_j = zeros(sizes[j])

Now the variables vector_1, vector_2, and vector_3 exist with the sizes you have asked for.

14

I am sorry if I could not deliver my point clearly from the beginning.
Thanks for pointing this out. I will be more precise and accurate next times to make the discussion more productive.
From a performance point of view, can you recommend someting?

15

That depends a lot on the performance of what. It is not possible to answer that without further information.