Use reco::formulaEvaluator instead of TFormula?

[pieterdavid]

From what I understood in CMSSW the reco::formulaEvaluator (from cms-sw/cmssw#11516 ) is preferred because it is thread-safe and faster than TFormula, and it's easy to include (almost standalone, and minimal public interface), so it may also be the better choice here (I'm using it in bamboo because the jet corrector classes rely on it, so I can prepare a PR - in the long run it may be worth asking for it to be released outside CMSSW if this option is taken).

[kirschen]

Good point. I was thinking about the consistency of JSON-format evaluator and the CMSSW-code in that context as well. There were some issues in the past with reco::formulaEvaluator not giving the same result as TFormula, e.g. cms-sw/cmssw#21851
So in any case for deliverables such as JEC the output of the JSON formula evaluator and the CMSSW-modules need to be validated against each other, no matter what the choice for the JSON formula evaluator.

[nsmith-]

Let me paste the readme section here for convenience:

Formula support is currently planned via linking to ROOT libraries and using TFormula,
however if possible we would like to avoid this external dependency. One alternative could
be using the boost.spirit parser with some reasonable grammar--
this is the approach used for CMSSW's expression parser.
There are also various C++ formula parsers such as ExprTk,
and the python bindings may be able to call into numexpr,
though, due to the tree-like structure of the corrections, it may prove difficult to exploit vectorization
at levels other than the entrypoint.

At least that answers the question I had in https://github.com/nsmith-/correctionlib/blob/51331ef9f101ede5ba830fc0fab3756c7030432f/src/correction.cc#L65 so indeed now there are at least three reasons to drop TFormula:

• ROOT dependency
• Slow to compile
• Not thread-safe

It would be interesting to know how fast reco::formulaEvaluator compiles (or probably rather it just is parsed into an AST). Perhaps @Dr15Jones can provide some input. One thing that I would like is to have a grammar defined, like how the reco::ExpressionEvaluator grammar is. The advantage is then we can also validate the grammar from the python side with something like lark. The other advantage is it may allow easy construction of parsers in other languages, e.g. javascript for a correction viewer web UI

[Dr15Jones]

The grammar is:

• floating point arithmetics ,
• binary comparison operations,
• math functions (which are identified as alpha followed by alphanumerics or double : and ending with '(' enclosing an expression which ends with ')' ),
• variables with the names 'x', 'y', 'z' and 't', and
• other variables (referred to as 'parameters') which are of the form of an integral value (0,1,...) enclosed in square braces, e.g. '[0]'.

The following test is meant to exercise all the behaviors:
https://github.com/cms-sw/cmssw/blob/master/CommonTools/Utils/test/testFormulaEvaluator.cc

[nsmith-]

Thanks! Was there any motivation for not using boost::spirit as you had done before? Pros/cons?

[Dr15Jones]

Much lighter weight. Unless you configure boost::spirit correctly it isn't guaranteed to be thread-safe.

[nsmith-]

This project looks promising: https://github.com/yhirose/cpp-peglib
It is a C++17 header-only PEG parser.
There is a playground even: https://yhirose.github.io/cpp-peglib/

[nsmith-]

I have no idea what I'm doing but I think this works:

EXPRESSION  <- ATOM (BINARYOP ATOM)* {
                 precedence
                   L - +
                   L / *
                   R ^
               }
BINARYOP    <- < [-+/*^] >
CALL        <- FUNCTION '(' EXPRESSION (',' EXPRESSION)* ')'
FUNCTION    <- < 'exp' | 'sqrt' | 'log' | 'log10' | 'TMath::Log' | 'max' >
ATOM        <- LITERAL / (UNARYOP? UATOM)
UATOM       <- NAME / CALL / '(' EXPRESSION ')'
UNARYOP     <- < '-' >
NAME        <- PARAMETER / VARIABLE
PARAMETER   <- < '[' [0-9]+ ']' >
VARIABLE    <- < [xyzt] >
LITERAL     <- FLOAT / INTEGER
FLOAT       <- < '-'? [0-9]+ '.' [0-9]* >
INTEGER     <- < '-'? [0-9]+ >
%whitespace <- [ \t\r\n]*

[Dr15Jones]

Here is the full list of supported functions
https://github.com/cms-sw/cmssw/blob/master/CommonTools/Utils/src/FormulaEvaluator.cc#L566-L609

[nsmith-]

I chose this solution in #18, the grammar is at https://github.com/nsmith-/correctionlib/blob/be611df854302519edb03442f90fcaa5e532a248/src/correction.cc#L45
If I set https://github.com/nsmith-/correctionlib/blob/be611df854302519edb03442f90fcaa5e532a248/src/demo.cc#L6 true then run the demo on the example data with 18k formulas (a btag SF file) I find it compiles the formulas about 200x faster than TFormula, and executes them a bit under 2x faster.