[Rivet] Prototype improved cuts system for Rivet

[Andy Buckley]

Hi everyone,

After several attempts (typically one day per 3 months!) I've managed to
make a prototype system for improved particle/jet selection cuts in
Rivet that seems workable. I'm still not completely happy, so have
posted a discussion of the motivation and my implementation on the
StackExchange Code Review site... have a look!

http://codereview.stackexchange.com/questions/17881/implementing-c-boolean-function-objects-with-logical-operator-combinations

This just uses integers for simplicity and accessibility to a general
audience, but is easily extended to more complex objects like particles
and jets.

The motivation is that we currently have quite restricted options for
specifying cuts on Projections, e.g. for FinalState we have the basic

FinalState(double ptmin, double etamin, double etamax)

constructor. But what if we want a ptmax? What if we want several
disjoint eta ranges? Or, just for neatness, if there is no ptmin and
we'd rather not have to explicitly write 0, or would rather not have to
type the - and + numbers for a symmetric |eta| range?  There is also no
safety check here for accidents like FinalState(-1.0, 1.0, 100*GeV) --
I've mixed up the argument ordering but the compiler just sees a bunch
of compatible doubles and ploughs on.

We can't hope to make all the possible combinatorics of cut signatures,
and anyway attempting to make those combinatorics would be killed by the
ambiguities between which ordering (or disjoint interpretation) of "n
doubles in a row" is intended in a given case. For constructors there's
no (sane) option to name the different functions differently, even if we
wanted to.

So the idea is to replace all the combinatorics that do exist and that
might be argued for with a single "Cut" argument. So the above example
would become

FinalState(PtGT(500*MeV) && ModEtaLT(2.5))

where the cut class names, with LT and GT for less/greater than, are
entirely open to iteration. This example doesn't help much, but consider
this more complex case with several eta ranges:

FinalState(PtGT(500*MeV) && (ModEtaIn(-2.5, -1.5) || ModEtaLT(1.0)) )

or even

FinalState(PtGT(500*MeV) && ModEtaLT(2.5) ||
           PtGT(100*MeV) && ModEtaIn(2.5, 4.8))

We could even think about putting in the particle properties like charge
and species here, cf. Charged/Neutral/IdentifiedFinalState via these
classifying functors.

Feedback, please! And do have a look on the StackExchange site if you
want to see a bit more detail and/or have suggestions for improvement.
If you like it, I'd like to try and get this into Rivet 2.0... or 2.1 if
that seems unrealistic.

Cheers,
Andy

-- 
Dr Andy Buckley, SUPA Advanced Research Fellow
Particle Physics Expt Group, University of Edinburgh

The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.