RVec and PyROOT: different behavior when reading vector or evaluating function

ROOT
1

Dear experts,

I’m getting a weird behavior when creating RVecs from C++ and reading it from PyROOT. If I declare a vector and read it from PyROOT, the result is the expected one. If I declare a function that returns a RVec and evaluate it from PyROOT, some elements are corrupted. In the example below, only the first two are corrupted, but a large vector will have more corrupted elements.

The even more intriguing thing is that, if I access by index, the items are correct.

Example:

import ROOT

ROOT.gInterpreter.Declare("#define N 10")

ROOT.gInterpreter.ProcessLine(
    "auto v = ROOT::RVec<double>(N); std::iota(v.begin(), v.end(), 0);"
)
print("Declare vector with cling and read it from PyROOT:")
print([val for val in ROOT.v])
print()

ROOT.gInterpreter.Declare(
    """
    auto make_vec()->ROOT::RVec<double> {
    auto v = ROOT::RVec<double>(N);
    std::iota(v.begin(), v.end(), 0);
    return v;
    }
    """
)
print("Declare function with cling and call it from PyROOT:")
print([val for val in ROOT.make_vec()])
print()

print("Declare function with cling and call it from PyROOT, reading items by index:")
values = []
vec = ROOT.make_vec()
for idx in range(vec.size()):
    values.append(vec[idx])
print(values)

Output:

Declare vector with cling and read it from PyROOT:
[0.0, 1.0, 2.0, 3.0, 4.0, 5.0, 6.0, 7.0, 8.0, 9.0]

Declare function with cling and call it from PyROOT:
[6.75340436e-316, 1.8924160061568907e-202, 2.0, 3.0, 4.0, 5.0, 6.0, 7.0, 8.0, 9.0]

Declare function with cling and call it from PyROOT, reading items by index:
[0.0, 1.0, 2.0, 3.0, 4.0, 5.0, 6.0, 7.0, 8.0, 9.0]

Is it a possible bug or is there something I’m missing?

ROOT Version: 6.32.02
Platform: Linux
Compiler: gcc13

2

Dear Felipe,

Thanks for the post: I can reproduce the issue, also on macOS.
I would even add another case, which seems to work, for completeness:

values = []
vec = ROOT.make_vec()
for i in vec:
    values.append(i)
print(values)
# prints [0.0, 1.0, 2.0, 3.0, 4.0, 5.0, 6.0, 7.0, 8.0, 9.0]

@jonas do you think this is a bug?

Cheers,
D

3

Thanks for the reply, Danilo. The case you proposed also works on Linux setup.

F.