-
Notifications
You must be signed in to change notification settings - Fork 3
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
Change representation of the luminosity function #165
Comments
This would be nice, such that we'll be able to do: grid.convolute(
...,
grid.lumis().iter().map(|(a, b, _, _)| myfilter(a, b)).collect(),
...
) |
Exactly, that's the idea, it should become much simpler. |
I'm no longer sure this is a good idea, and I'm closing this in favour of #149, which should allow implementing an operation that 'splits' each channel of a luminosity function that the new channels contain FK table-like entries, in the sense that we have a single tuple |
At result level or at grid level? Because I would not recommend the second, I definitely want to avoid copying subgrids. Now I really appreciate that the concept of |
See #149 (comment). That copies subgrids, which is unavoidable for duplication of them. |
The current representation of the luminosity function, which is essentially the type
LumiEntry
, makes it very hard to convolute a grid for a single tuple of partons only, see also #150. We should:Grid::lumis
that returns simply aVec
/slice
of tuples(a, b, factor, index)
witha
andb
being the two partons andindex
being the same each tuple from the sameLumiEntry
theGrid
was constructed with. The methodGrid::lumi
should be removedGrid::convolute
function to accept a slice of boolean that correspond now to the slice returned byGrid::lumis
instead of the shorter vector ofLumiEntry
objects theGrid
was constructed with. This will allow more fine-grained control over convolutions.The text was updated successfully, but these errors were encountered: