-
Notifications
You must be signed in to change notification settings - Fork 6
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add support for Generalised k_T in reconstruction interfaces #49
Comments
Hello Graeme. I don't understand your point. By definition in the generalized kt algorithm the exponent is a parameter. Named switch can be added for convenience, but to support the generalized algorithm, we need the exponent to be a parameter (p ∈ℝ) when the switch is set to generalized_kt. For e+e-, we need an extra switch to use E instead of pt, and change (ΔRij/R)² term by the one used for e+e-. |
Hi @grasph - thanks for he comment. Mathematically I agree with you, but does anyone ever use an arbitrary power? I only ever saw -1, 0, 1. Of course, we can continue to support arbitrary powers if they are desired. Indeed, for the e+e- algorithms (#50 #51) I think a lot of code can be shared with the current pp algorithms, if we make the appropriate measures parameters. |
I'm not aware of use of different power parameter values than -1, 0, 1, but as supporting any parameter value comes from free, I think we should not restrict the software to these values. This generalization that formulates in a consistent manner the different historical algorithms is very elegant. I suggest defining constants kt_power_parameter, antikt_power_parameter and cambridge_aachen_power_parameter, to be used as the power parameter, instead of adding a parameter selecting the algorithm and ending with two ways to select the same algorithm (specific algorithm / generalized_kt with proper power parameter). |
Updating this issue to support properly a generalised k_T algorithm for pp in
For the fixed power algorithms, AntiKt, CA and Kt these should be specifiable either via their power value or their algorithm type (if both are given these must be consistent). |
Currently the main interface to the two reconstruction strategies takes the power for the$d_{ij}$ metric as an argument, which then switches between the anti-kt, CA and kt versions (-1, 0, 1).
However, this is only good for these$pp$ algorithms and doesn't account for, e.g., the $e^+e^-$ algorithms, such as the generalised $k_T$ .
So it's better to switch to steering with the explicit algorithm name and not a power value as a proxy.
The text was updated successfully, but these errors were encountered: