Closed beojan closed 4 years ago
Yeah, I see: it's thinking that an individual element is one element of the underlying Numpy array (i.e. what you get when you say array[n]
for some integer n
), but since the Numpy array is two-dimensional, array[n]
gives you an array, and that can't be passed into float
(hence the error message).
In the Awkward 1.0 project, I'm erasing the difference between Awkward arrays and Numpy arrays at a structural level, to fix all of this kind of bug once and for all.
For now, though, can you work with jagged arrays of TLorentzVector
? Even though you know that you'll always have 2 Lorentz vectors in each element, if you technically make it jagged, it will work. (It's a case that many people have tested.) Instead of creating x
, y
, z
, t
directly with np.ones
, pass the np.ones
through awkward.fromiter
(slow) or build the jagged array manually using JaggedArray.fromcounts(np.full(N, 2, dtype=int), content)
(fast).
That helped. I used JaggedArray.fromregular
.
Unfortunately, JaggedArray
can't slice in more than two dimensions (I actually have four), but I can do what I'm doing now since I can flatten out most of these dimensions.
Oh, the irony:
I just finished arbitrarily deep slicing in the new Awkward and consider it one of the motivators for this project. In pure Numpy, each level of slicing depth adds complexity, particularly because of Numpy's weird rules for advanced indexing. Without having to express everything in Numpy calls, it can be a recursive procedure that's completely self-similar and still vectorizable.
I hadn't known that anyone using awkward-array was actually running into this two-level slicing constraint—I never heard any feedback about it. However, I was pretty uncomfortable with the artificiality of the limitation.
I can create them:
And print their mass:
But I can't print the array itself:
Or add along only the inner axis, since
sum
takes no axis argument.