Open jmduarte opened 4 years ago
Hrmmm I think it would be best if we returned sign(z)*np.inf. I think that's better than returning some ridiculous number.
@jpivarski Your thoughts?
We never claimed that these Lorentz vectors would have the same behavior as ROOT TLorentzVectors, except inasmuch as they approximate the same mathematical system.
We should think about the limit points. Special floating point values like nan and inf are better than raising exceptions for datasets that are large enough to almost certainly contain pathologies. (It's also possible that arrays of Lorentz vectors have different special cases than individual objects, and that's something that we should synchronize.) But 10e10
for such a case is not something to emulate. Such a thing would stick out as an artificial feature in a histogram and must have been rediscovered by many students. (Especially consider the case of converting data from these eta values into x and y—there would be a strange ring...)
Also worth considering is that these Lorentz vectors are planned to be replaced with the vector
package. @henryiii might have something to add about that, although I understand that schedules are in flux at the moment.
I agree with @lgray. That fixed 10r10 can only harm you down the line in a non-trivial way …
Note that we can do better in these limits for rapidity, which you can still calculate from tanh^{-1}(p_z/E)
for a particle with non-zero mass.
Hi,
I'm wondering if we want to reproduce the behavior of ROOT.TLorentzVector for
eta
in the case thatx, y = 0
(See https://root.cern.ch/doc/master/TVector3_8cxx_source.html#l00320). That is, ROOT returnssign(z)*10e10
.Currently, uproot-methods throws a
ZeroDivisionError
:But maybe this behavior is desired?
Thanks, Javier