Strange beaviour of TGraph and numpy array

ROOT
1

The original question was posted here:

stackoverflow.com/questions/2984 … management

2

Hi,

PyROOT only passes flat, 1-dim arrays, as that is the only thing that can be handed through a pointer.

Cheers,
Wim

3

do you have the same issue using C++ code ?

4

[quote=“wlav”]Hi,

PyROOT only passes flat, 1-dim arrays, as that is the only thing that can be handed through a pointer.

Cheers,
Wim[/quote]

Hi, thanks for your answer. But I don’t get it.

ac = np.empty([4,4], np.dtype(‘float64’))

Then ac[:,1] should be the same thing as:

ac_1d = np.empty(4, np.dtype(‘float64’))

for instance if I do np.shape(ac[:,1]) I get (4,)
and if I do np.shape(ac_1d) I get the same.

With other words I thought ac[:,1] is flat, 1-dim array … seems I’m wrong about it, but I don’t see why …

cheers, Asen.

5

Hi,

well, things are what they are. I get a segment count of 0 for the buffer from ac[:,1], and 1 for ac_1d. Looking at the implementation, it’s 1 or 0 as the only options. But if the segment count is returned as 0 (really meaning ‘not 1’), then the code has to reject it. Don’t see any other way.

(In fact, the numpy code itself, even if PyROOT were to let the segment check pass, refuses to serve a readbuf for arrays that are not a single segment: it, too, checks for segments first.)

Cheers,
Wim

6

Is this possibly because the slicing of a numpy array returns an “array view” kind of object that accesses the same memory as the original array, but has built-in non-zero strides and such? From what I remember the [:] notation was supposed to make a real new copy of the contents, but I might be misremembering.

Jean-François

7

Jean-François,

could be: they reference the same memory.

Cheers,
Wim