how to add two LorentzVector?

[ZhenxuanZhang-Jensen]

I am trying to add two jets together to form a W boson in the >=4 jets category. I load a paquent file, and the events['SelectedJet_*'] type are all awkward.highlevel.Array and I write like:

cat_4jets_jets_pt = events['SelectedJet_pt'][ak.num(events['SelectedJet_pt']) >= 4]
cat_4jets_jets_eta = events['SelectedJet_eta'][ak.num(events['SelectedJet_eta']) >= 4]
cat_4jets_jets_phi = events['SelectedJet_phi'][ak.num(events['SelectedJet_phi']) >= 4]
cat_4jets_jets_mass = events['SelectedJet_mass'][ak.num(events['SelectedJet_mass']) >= 4]

cat_4jets_jets_LV =  vector.awk({
    "pt": cat_4jets_jets_pt,
    "phi": cat_4jets_jets_eta,
    "eta": cat_4jets_jets_phi,
    "M": cat_4jets_jets_mass,
})

cat_4jets_jets_LV[0,1] + cat_4jets_jets_LV[0,2]

And the last line has a bug : ValueError: cannot broadcast records in this type of operation
Is this mean I don't use the Momentum4D in the right way? how can I fix this? thanks

[jpivarski]

@Saransh-cpp, this is a problem with the vector.awk constructor: it allows users to construct arrays of vectors with incorrect types without any warning. For instance, if I have four jagged arrays with the same list lengths,

>>> import awkward as ak
>>> pt = ak.Array([[1, 2], [], [3]])
>>> eta = ak.Array([[1, 2], [], [3]])
>>> phi = ak.Array([[1, 2], [], [3]])
>>> mass = ak.Array([[1, 2], [], [3]])

then what I want to create is three lists of vectors, two in the first list and one in the last. But vector.awk is too literal:

>>> wrong_types = vector.awk({"pt": pt, "eta": eta, "phi": phi, "mass": mass})
>>> print(wrong_types.type)
3 * Momentum4D["rho": var * int64, "phi": var * int64, "eta": var * int64, "tau": var * int64]

This is three vectors, and the attributes have list type. Components of vectors may be integers or floats, but they shouldn't be allowed to be lists!

What we really wanted in this case was the ak.zip of these four jagged arrays:

>>> right_types = vector.awk(ak.zip({"pt": pt, "eta": eta, "phi": phi, "mass": mass}))
>>> print(right_types.type)
3 * var * Momentum4D["rho": int64, "phi": int64, "eta": int64, "tau": int64]

so that we now have three lists of vectors. The problem (which @ZhenxuanZhang-Jensen ran into) is that vector.awk should have figured this out.

Note: with this correction, it's possible to add vectors.

>>> right_types[0, 1] + right_types[2, 0]
<MomentumRecord4D ... phi: 2.61, eta: 2.83, tau: 6.57} type='Momentum4D["rho": f...'>

The object and NumPy backends do type-checking. The Awkward Array backend is harder to check like that (if the vectors are buried inside a data structure, they're not represented by a Python type, so we can't run code to check their correctness; also, we don't want correctness checks after every slice!). However, this vector.awk is a function in the Vector library; it should be possible to add a type check.

We wouldn't want the fields of vectors to be boolean or complex, either. (I don't think the object or NumPy backends check that, though.)

[agoose77]

Also, note that one can use vector.zip for the zip equivalent of vector.awk

[jpivarski]

I missed or didn't remember about that. Anyway, I've seen mistakes made with vector.awk more than once, and sometimes by me. At the very least, it should not allow wrong types to be constructed.

I do remember your feature request for behavior classes to have class validation (scikit-hep/awkward#1483), which could be appropriate here, if it's not a performance concern checking and re-checking the types of the coordinate attributes every time an array gets sliced. Even without that, though, vector.awk (and vector.zip, I guess) could check the types, and if the check is put here, it would happen only once.

[Saransh-cpp]

Yes, vector.zip can be used here. A type check should definitely be added to the awk constructor with some tests. I'll take this up!

Also, the object and numpy backend allows users to pass in lists for a single coordinate value. The docstrings warn the user -

No constraints are placed on the types of the coordinate attributes, but
if they are not numbers, mathematical operations will fail. Usually, you want
them to be int or float.

and passing in a list of values does break a lot of mathematical operations.

Should I add checks in them too? Or is there a situation where a user would want to construct a vector like this -

>>> y = vector.array([
...     (1.1, [2.1, 9])
... ], dtype=[("x", float), ("y", list)])
>>> y
VectorNumpy2D([(1.1, list([2.1, 9]))], dtype=[('x', '<f8'), ('y', 'O')])

[jpivarski]

I have a grudge against dtype=object arrays; they seem like they're going to be efficient NumPy arrays, but they aren't.

It seems like a good idea to me—as in, "I vote for"—type checks in constructors accessible to users on all backends. This (Discussion) isn't the first time errors have been reported after an incorrect construction is silently ignored. In some cases, I've done it myself.

It would be nice to avoid the performance penalty of runtime type-checks for vectors constructed from other vectors, through the transformation methods. That is, ensure that the user input satisfies type constraints and then derivations would be known to satisfy those type constraints as a consequence of their algorithms. (For instance, given an array in which all elements are floating point numbers, calling unit on it will make a unit vector of floating point numbers because **2, +, sqrt, and / all turn floats into floats.)

I should say, as long as this is a backend-dependent type-check. I've mentioned before that I think it would be a tour de force (and maybe also useful!) to add a SymPy backend, in which the fields are all SymPy Symbols. They'd pass through the mathematical formulae in the compute module by duck-typing, and then we'd have all of these methods symbolically, as well as numerically. The compute module should be general enough to let that happen. But adding type-checks that insist on numerical fields would break that.

Another case that would be broken, less exotic than SymPy: a CuPy backend would be easily possible, and then Vector calculations would run on GPUs. But CuPy doesn't like numbers to be Python objects—e.g. the number 2 needs to be a cp.array(2)—so that they can reside on the GPU. Insisting on all fields being Python numbers would be very wrong for CuPy.

But a backend-dependent type check on the constructors would be good. (I think all of the constructors are backend-dependent, now that I think of it.)