[Rivet] New projection method names without "projection"

[Christian Gutschow]

Hi David,

that’s a good point actually. What about 'prepare'? Just o throw one more option in ;-)

Cheers,
Chris

On 13 Jun 2016, at 10:54, David Grellscheid <david.grellscheid at durham.ac.uk<mailto:david.grellscheid at durham.ac.uk>> wrote:

I still prefer schedule over declare, exactly _because_ it has the implication that it is something that will be run. The caching and so on is an implementation detail users don't need to bother with.

declare is too computer sciency for me. With that background you know what it means, but the generic meaning of declare is not really useful for us.

 David


On 12/06/2016 02:06, Christian Gutschow wrote:
Oh I like declare! I think that’s my favourite of all the suggestions. Yes, let’s go for that one if there are no objections?

Chris

On 11 Jun 2016, at 22:24, Andy Buckley <a.g.buckley at gmail.com<mailto:a.g.buckley at gmail.com><mailto:a.g.buckley at gmail.com>> wrote:

I read appoint as annoint, which is even better ;-) Perhaps also consecrate, sanctify, or bless?

But more seriously, I thought of "declare" earlier today and am not sure why it didn't come to mind sooner. For me it is at least as nice as "register" -- in fact, we already use it in the macro that registers/declares analysis plugins (and no, I don't think there's any danger of confusion). And way more appropriate than "add", IMHO. What do you think, can we use it?

Andy


On 10/06/16 22:17, Christian Gutschow wrote:
Hi Andy, all,

schedule seems alright to me. Here are some more alternatives for the
brainstorming: commission, employ, engage, enlist, appoint, establish. ;-)

Cheers,
Chris
On 10 Jun 2016, at 20:58, Andy Buckley <andy.buckley at cern.ch<mailto:andy.buckley at cern.ch><mailto:andy.buckley at cern.ch>
<mailto:andy.buckley at cern.ch>> wrote:

Ha, we had the same response to "register" being forbidden!

I certainly agree with dropping reg().

schedule() is not bad -- I'd like to know what others think. The only
flaw is that to me it implies that that projection will be run at a
set time / order, while in practice it's lazy (and the result may
already be cached).

enroll() / enrol() will probably suck others into that US/other
spelling trap ;-)

record() is not quite right -- I feel like it specifies writing
something to disk immediately.

And catalog()... I don't really know what that implies.

Grr, words. Right, I'm going to try and have a weekend now, and let
this little word puzzle itch away in the background. Feel free to join
me in this bikeshedding: names are important ;-)

Andy



On 10/06/16 17:30, David Grellscheid wrote:
Hi Andy,

Here's my preference (after some thesaurus googling):

drop add() and reg()

use schedule(), enroll(), record() or catalog() instead of register()

We shouldn't multiply names for the same functionality. One deprecated
name and one replacement is enough.

See you,

 David



On 10/06/2016 16:30, Andy Buckley wrote:
Ah, I see!

Anyway, yes we have had feedback that people don't really understand how
the concept maps to the Rivet code so I think hiding by default is a
good thing. And if it allows us to have shorter function names without
losing clarity, that's no bad thing.

I've implemented this on the 2.5 branch now. The one stumbling block was
with the idea of register(someproj, "SomeName"): 'register' is a C(++)
keyword, so I think we can't use it as a function name -- right? For now
I've created aliases for addProjection called both add(...) and
reg(...): any better ideas, or a preference to drop one? While I prefer
the name "register" to "add", given that addProjection is being retained
and that "reg" is not so obvious to remember or interpret, I'm inclined
to ditch it. Thoughts?

Andy


On 24/05/16 14:17, Leif Lönnblad wrote:
On 2016-05-24 00:06, Andy Buckley wrote:
On 23/05/16 22:31, Frank Siegert wrote:

I quite like the picture, but a) the algebraic mapping is not exact
because you can't actually do P(P(Event))

In fact that was how the original design intended things to work,
but it
was lost along way. Don't quite remember why.

Anyway, I don't mind hiding the word from the users, if they are
confused by it.


/Leif


_______________________________________________
Rivet mailing list
Rivet at projects.hepforge.org<mailto:Rivet at projects.hepforge.org><mailto:Rivet at projects.hepforge.org> <mailto:Rivet at projects.hepforge.org>
https://www.hepforge.org/lists/listinfo/rivet




--
Dr Andy Buckley, Lecturer / Royal Society University Research Fellow
Particle Physics Expt Group, University of Glasgow
_______________________________________________
Rivet mailing list
Rivet at projects.hepforge.org<mailto:Rivet at projects.hepforge.org> <mailto:Rivet at projects.hepforge.org>
https://www.hepforge.org/lists/listinfo/rivet




 —

 Dr. Christian Gütschow

 TU Dresden
 Institut für Kern- und Teilchenphysik
 Zellescher Weg 19
 01069 Dresden

 > at CERN: 104-02-C02
 > at IKTP: E17, ASB
 > chris.g at cern.ch<mailto:chris.g at cern.ch> <mailto:chris.g at cern.ch>







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




 —

 Dr. Christian Gütschow

 TU Dresden
 Institut für Kern- und Teilchenphysik
 Zellescher Weg 19
 01069 Dresden

 > at CERN: 104-02-C02
 > at IKTP: E17, ASB
 > chris.g at cern.ch<mailto:chris.g at cern.ch>









 —

 Dr. Christian Gütschow

 TU Dresden
 Institut für Kern- und Teilchenphysik
 Zellescher Weg 19
 01069 Dresden

 > at CERN: 104-02-C02
 > at IKTP: E17, ASB
 > chris.g at cern.ch<mailto:chris.g at cern.ch>





-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.hepforge.org/lists-archive/rivet/attachments/20160613/ce38e101/attachment.html>