[Rivet] New projection method names without "projection"

Andy Buckley andy.buckley at cern.ch
Mon May 23 23:06:58 BST 2016


On 23/05/16 22:31, Frank Siegert wrote:
> Hi Andy,
>
>> As some of you at the MCnet Computing School last week (which was excellent,
>> by the way) know, I think we made a mistake when we used the word
>> "projection" to name a concept in Rivet.
>
> For those of us who were not at the school last week, could you
> explain why Projection is a misnomer? I always liked it, as it is a
> concise wording which still captures exactly the functionality.

I quite like the picture, but a) the algebraic mapping is not exact 
because you can't actually do P(P(Event)), b) the caching feature should 
not be something users typically need to think about, and c) my 
experience is that users really do not get it... it's certainly not 
intuitive until someone explains the relevant mental picture. 
"Calculator" or "Observable" might have been better choices from the 
user point-of-view.

>> We're too far down the rabbit-hole to completely reverse that now, but we
>> can reduce the number of times that normal users have to encounter the word
>> "projection".
>
> I'll admit to being a boring conservative here, who has been scolded
> too often for user-facing changes (though I think we have been pretty
> good over the last months or even year(s)). While I'm not strictly
> against such changes, I'd prefer to limit them to really good reasons.

We intend to keep Rivet alive for another 10 years or more, I think. 
That means that change is inevitable as requirements change -- it's how 
we manage it that matters. I don't think this is a critical thing, but I 
think a great deal of our success so far is due to interface 
intuitiveness: users find Rivet "natural" and easy to get from zero to 
something useful. If we want to keep expanding that collection of coding 
users -- and I do, especially into the BSM realms of the experiments -- 
then I think it's worth polishing this last, unintuitive corner of the API.

>> For addProjection, the "Projection" part of the name is redundant because
>> the argument type is an object derived from Projection. But I don't think
>> "add" is a very clear name anyway, so maybe something like register(myproj,
>> "MyObs") would be better? We could have "add" as another alias to ease the
>> transition from addProjection.
>
> Would the plan be to leave all three  (addProjection, register, add)
> functioning forever, or would one or two be obsoleted at some point?

I don't know about super-long-term, but in the short-term I would regard 
my proposal as being for co-exiting synonyms. Arguably the ones with the 
"projection" in the name are more suitable for internal Projection 
implementation where the author needs to know what's going on under the 
hood, while the "projection"-less variants are syntactic sugar for the 
"casual" user who just wants to implement their analysis as quickly & 
easily as possible.

Andy

-- 
Dr Andy Buckley, Lecturer / Royal Society University Research Fellow
Particle Physics Expt Group, University of Glasgow


More information about the Rivet mailing list