You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Jan 27, 2023. It is now read-only.
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.
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
The text was updated successfully, but these errors were encountered: