Skip to content
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

Closed
graeme-a-stewart opened this issue Jun 4, 2024 · 4 comments · Fixed by #71
Closed

Add support for Generalised k_T in reconstruction interfaces #49

graeme-a-stewart opened this issue Jun 4, 2024 · 4 comments · Fixed by #71
Assignees
Labels
interface Changes to any public interfaces

Comments

@graeme-a-stewart
Copy link
Member

graeme-a-stewart commented Jun 4, 2024

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.

@graeme-a-stewart graeme-a-stewart added the interface Changes to any public interfaces label Jun 4, 2024
@grasph
Copy link
Member

grasph commented Jun 7, 2024

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-.

@graeme-a-stewart
Copy link
Member Author

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.

@grasph
Copy link
Member

grasph commented Jun 14, 2024

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).

@graeme-a-stewart graeme-a-stewart changed the title Invoke algorithm by enum, not by power value Add support for Generalised k_T in reconstruction interfaces Jul 26, 2024
@graeme-a-stewart
Copy link
Member Author

Updating this issue to support properly a generalised k_T algorithm for pp in (y, \phi).

  • Add new reconstruction algorithm type, GenKt
  • For this algorithm this type, plus a specific p value needs to be passed

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).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
interface Changes to any public interfaces
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants