[Rivet-svn] rivet: 3 new changesets

[Rivet Mercurial]

details:   https://rivet.hepforge.org/hg/rivet/rev/f475bd1fcc0c
branches:  release-2-6-x
changeset: 6251:f475bd1fcc0c
user:      Andy Buckley <andy at insectnation.org>
date:      Tue Mar 13 15:29:17 2018 +0000
description:
Doc updates to describe Cuts and getEnvParam

details:   https://rivet.hepforge.org/hg/rivet/rev/3bb05fe53ff6
branches:  release-2-6-x
changeset: 6252:3bb05fe53ff6
user:      Andy Buckley <andy at insectnation.org>
date:      Tue Mar 13 16:48:01 2018 +0000
description:
More doc updates

details:   https://rivet.hepforge.org/hg/rivet/rev/08184a1b8962
branches:  release-2-6-x
changeset: 6253:08184a1b8962
user:      Andy Buckley <andy at insectnation.org>
date:      Tue Mar 13 16:48:29 2018 +0000
description:
Add typedefs for collections of four-vectors: FourVectors and FourMomenta

diffs (truncated from 211 to 50 lines):

--- a/doc/writinganalyses.tex	Thu Mar 08 14:35:55 2018 +0000
+++ b/doc/writinganalyses.tex	Tue Mar 13 16:48:29 2018 +0000
@@ -439,8 +439,28 @@
 %   addCut("PT", MORE_EQ, 3.0*GeV);
 % \end{snippet}
 
+\begin{philosophy}
+  We are often asked if there is a way to pass parameters to Rivet analyses, to
+  change their behaviour. This is potentially very useful when e.g. protopying
+  an analysis or optimising cuts. We have resisted it, however, because it would
+  jeopardise the core Rivet mission of preserving experimental analyses which
+  ``do the right thing'' to reproduce experimental results without any specific
+  parameter-passing being necessary: we fear that if parameterised analyses
+  become ``normal'', it will be much harder to do broad validation and testing
+  against large swathes of the analysis collection. Maybe we are too pessimistic.
 
-\subsection{Utility classes}
+  Anyway, you can still pass parameters to non-preservation analyses via
+  environment variables, and in fact we provide a \code{getEnvParam} function to
+  help you with this. For example, you might put in your code: \code{double x =
+    getEnvParam<double>("X", 10.0)}, and then on the command-line call
+  \kbd{X=17.5 rivet -a MYANALYSIS}: the \kbd{X} variable will be read, converted
+  to a double, and stored in the \code{x} variable; if it is not set, the value
+  will default to 10. Hopefully this will satisfy the most enthusiastic
+  analysis-parametriser!
+\end{philosophy}
+
+
+\subsection{Utility classes and functions}
 
 Rivet provides quite a few object types for physics purposes, such as three- and
 four-vectors, matrices and Lorentz boosts, and convenience proxy objects for
@@ -479,36 +499,144 @@
 \code{deltaR(vec1, vec2)}. Angles between such vectors can be calculated via the
 similar \code{angle(vec1, vec2)} functions.
 
+\begin{warning}
+  Developers' note: We should be specific about the type of rapidity used in
+  $\Delta{R}$ calculations\dots and change the default? Pseudorapidity naively
+  corresponds better to detector geometry than rapidity, but it has been shown
+  that this is not true for jets (and presumably also composite particles).
+\end{warning}
+
+\subsubsection{\code{Cut}s}
+The \code{Cut} system is a very powerful innovation in Rivet, allowing clear and
+self-documenting expression of arbitrarily complex kinematic cuts without
+needing lots of function overloads, or falling foul of type ambiguities.
+
+First, let's explain the problem with the original \code{FinalState}
+constructor: \code{FinalState(double, double, double)}. What do these parameters