Out of bounds index access on TVector3 etc. is unpythonic

In [3]: v = ROOT.TVector3(1, 2, 3)

In [4]: v[3]
Error in TVector3::operator()(i): bad index (3) returning 0
Out[4]: 0.0

I think this method should raise an IndexError so that Python native functions that attempt to use it as a sequence don’t just loop forever.

Example:

l = list(v)

Should give you [1, 2, 3]

But instead, it loops forever, eating memory:


Error in TVector3::operator()(i): bad index (419580) returning 0
Error in TVector3::operator()(i): bad index (419581) returning 0
Error in TVector3::operator()(i): bad index (419582) returning 0
Error in TVector3::operator()(i): bad index (419583) returning 0

Hi,

pythonization has been added for TVectorT, see this topic: http://root.cern.ch/phpBB2/viewtopic.php?t=6285. Individual classes with numbers in their name would otherwise have to be handled each and everyone by hand.

Cheers,
Wim

Are you suggesting we add that or just put up with the odd behaviour?

Hi,

I’d say use TVectorT, which I believe is recommended anyway?

Cheers,
Wim

Hi Wim

I’m using TVector3 for vectors in 3-space from which I want to measure angles between and perform rotations on them etc. I thought TVectorT was more like the STL Vector class, and doesn’t have any of these rules, no?

Hi,

no, TVectorT is for matrix operations and such, not container like. In addition, if TVector3 is used for physics operations, than why care about the list operations (those are going to be slow … ). Anyway, I’ll presume you know best … I put a pythonization in SVN trunk.

Note that I was hoping to have at least some signature that I could hook the pythonization on (like GetSize() or something), but there is no such thing. TVector2 is even more different and does not even have an indexing operator (hence I did not add a similar pythonization for that one).

Cheers,
Wim

Wim,

It looks like you misunderstood what TVector3 and TVector2 are doing.
There is nothing dynamic in these 2 classes. TVector3 is a Physics object
handling 3 components (typycally x,y,z or px,py,pz). No point in having a GetSize for these 2 classes.

Rene

Rene,

that I understood, but alex-weej wants to perform list operations on it (which I did not understand, as said above). Now to add such operations on a class that wasn’t meant to be used in such a way, means hand-coding those pythonizations, which I thought more work than worth (but in the end, discussing it is even more work, so I did add them).

Note that any class that has an integer indexing operator (such as TVector3, but not TVector2) automatically becomes iterable (is a Python feature, not a PyROOT one, and is actually quite annoying for std::map<int,T> … ). Anything with an indexing operator and something known that yields a size automatically becomes range-checked (PyROOT feature), w/o the need of manual coding the pythonizations.

Cheers,
Wim