|
[Rivet] New projection method names without "projection"Andy Buckley andy.buckley at cern.chMon 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 |