<div dir="ltr">Hi Andy, all,<div><br></div><div>I'm very confused ;-)</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span style="font-size:12.8px">So the problem is not that we have one function for b-tagging b-jets, another for b-tagging light jets, etc., but that we have one sort of efficiency function for b-tagging, one for c-tagging, and one for jet reco... and all have the same function signature. That means that I need to treat each tagging as being something distinct from the rest of the smearing/efficiency simulation, because the compiler can't tell if a Jet->double function means reco efficiency or some sort of tagging (which one?).</span></blockquote><div><br></div><div>Can you explain this perhaps with an example? Why does the compiler need to know the difference? I would have thought that the analysis would have to tell the compiler explicitly this kind of thing, but it sounds like you're aiming for something more automated.</div><div><br></div><div>Chris<br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jul 18, 2017 at 10:16 AM, Andy Buckley <span dir="ltr"><<a href="mailto:andy.buckley@cern.ch" target="_blank">andy.buckley@cern.ch</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi James!<br>
<br>
We handle fakes (i.e. mistags) with the same function that does true-tag efficiency. The user-supplied tagging efficiency function can ask questions of the truth jet, like bTagged() and cTagged(), so the typical implementation is a fall-back of b-tagging rates for true b-jets, then true c-jets, then maybe true taus, then light.<br>
<br>
You're right that in general these should be mappings on *any* physics object, and I have some plans for that... but for now Particle and Jet are a bit too distinct.<br>
<br>
So the problem is not that we have one function for b-tagging b-jets, another for b-tagging light jets, etc., but that we have one sort of efficiency function for b-tagging, one for c-tagging, and one for jet reco... and all have the same function signature. That means that I need to treat each tagging as being something distinct from the rest of the smearing/efficiency simulation, because the compiler can't tell if a Jet->double function means reco efficiency or some sort of tagging (which one?). Thoughts on how to get around this without making the user do something horrible?<span class="HOEnZb"><font color="#888888"><br>
<br>
Andy</font></span><div class="HOEnZb"><div class="h5"><br>
<br>
<br>
On 18/07/17 08:08, James William Monk wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi Andy,<br>
<br>
(I know I’m pretty quiet on this list, but I do still lurk!)<br>
<br>
Do you handle fakes separately?  If not, why does the API need to distinguish between light and b-jets?  It is legitimate to ask it “what is the probability that this light jet is reconstructed as a b-jet.”  In fact, you ought to be able to ask that about any object, not just jets.  From an analysis point of view, all you care about is how many b-jets you reconstruct, so does it make sense to distinguish between fakes and true jets (other than for debugging purposes)?<br>
<br>
cheers,<br>
<br>
James<br>
<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On 17 Jul 2017, at 18:03, Andy Buckley <<a href="mailto:andy.buckley@cern.ch" target="_blank">andy.buckley@cern.ch</a>> wrote:<br>
<br>
Hi Riveters,<br>
<br>
A C++ design question for you all... ;-)<br>
<br>
Those who were at the Lunga hackfest last year (yes, we want to do it again!) might remember that we decided to convert the efficiency function + smearing function approach to our fast-sim, to instead take an ordered list of unified transform functions which would operate on, and return, {object,eff} *pairs*.<br>
<br>
At the time, Karl implemented a bunch of macro trickery on a branch, and I recently converted it with some C++11 magic to a funkier form that didn't require users (i.e. analysis authors) to add confusing make_pair calls to their only-smearing or only-efficiency functions (and lambdas).<br>
<br>
This works beautifully for SmearedParticles -- C++ nerds might want to look up variadic template functions and geek out -- but with SmearedJets there's an additional complication: tagging. From function signatures alone there's nothing to distinguish a Jet->double jet reco efficiency function (usually ~100% and ignorable) from a Jet->double b-tagging function (important), or indeed from a Jet->double c-tagging function (haven't used it yet, but never say never). Or tau tagging, which doesn't exist yet, but...<br>
<br>
So, any bright ideas of how we can distinguish reco/b-tag/c-tag/tau-tag efficiency functions? A possibility would be to return not just a double, but a {pid,eff} = {int,double} pair where the first element is the PID. But I'm hoping you can suggest something nicer!<br>
<br>
Not a critical thing, but if we're going to polish the interface like this, we might as well do it properly. This would also have the nice, in principle, effect of allowing tagging efficiencies to be applied at a user-defined stage of reconstruction: at the moment the tagging is all applied based on the post-smearing kinematics.<br>
<br>
Cheers,<br>
Andy<br>
<br>
-- <br>
Dr Andy Buckley, Lecturer / Royal Society University Research Fellow<br>
Particle Physics Expt Group, University of Glasgow<br>
______________________________<wbr>_________________<br>
Rivet mailing list<br>
<a href="mailto:Rivet@projects.hepforge.org" target="_blank">Rivet@projects.hepforge.org</a><br>
<a href="https://www.hepforge.org/lists/listinfo/rivet" rel="noreferrer" target="_blank">https://www.hepforge.org/lists<wbr>/listinfo/rivet</a><br>
</blockquote>
<br>
</blockquote>
<br>
<br>
-- <br>
Dr Andy Buckley, Lecturer / Royal Society University Research Fellow<br>
Particle Physics Expt Group, University of Glasgow<br>
______________________________<wbr>_________________<br>
Rivet mailing list<br>
<a href="mailto:Rivet@projects.hepforge.org" target="_blank">Rivet@projects.hepforge.org</a><br>
<a href="https://www.hepforge.org/lists/listinfo/rivet" rel="noreferrer" target="_blank">https://www.hepforge.org/lists<wbr>/listinfo/rivet</a></div></div></blockquote></div><br></div>