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