Make package work on more general numerical types

[graeme-a-stewart]

Betraying its R&D origin (😊) our jet types are currently locked down to Float64. Time to change this! We should have parameterised types T where T <: Real.

To be fair, integer types don't make much sense, but, e.g., ForwardDiff states The target function must be written generically enough to accept numbers of type T<:Real as input.

[Moelf]

(or just don't target ForwardDiff)

[graeme-a-stewart]

That was more an example of why it might be useful - we certainly want to go to at minimum AbstractFloat to support Float32.

However, I was having a discussion with @lukasheinrich yesterday and he does have interest in differentiable jet finding, so maybe it could really be useful...

[Moelf]

that's an interesting idea -- I never thought about the differentiability of anti-kT, what are some possible applications?

I'm thinking about in terms of what is {y} and {x} in the gradient of d{y}/d{x}?

[graeme-a-stewart]

Wouldn't it be more like $\frac{d_{physics}}{dR}$, where $R$ is the cone radius (or $\frac{d}{dp}$, with the clustering power parameter)?

[Moelf]

I thought about them but then it doesn't make that much sense to me -- dR is probably scanned / optimized for something, I don't see us pushing a different dR through ATLAS as the new "ak4".

dp is more weird, I guess technically it's a continuous variable, but -2, -1, -0.5, 0, 1, 2 are somewhat special -- also, if we use anything non-integer and non-0.5, running them in HLT will be super slow....