Different parsing of TCut strings in CINT an PyROOT

Hi,

with PyROOT I can do

import ROOT as r

t = r.TNtuple('t','', 'x')
t.Fill(-1)
t.Scan('fabs(x)')     # show one row with entry 1

while the equivalent in CINT

{
TNtuple t("t","", "x");
t.Fill(-1);
t.Scan("fabs(x)");
}

produces

Error in <TTreeFormula::Compile>:  Bad numerical expression : "fabs(x)"

I see both processes load libm and have a hard time making a consistent picture what is allowed when (but I like fabs being available in PyROOT). Could someone enlighten me how that difference comes about?

Hi,

not my cup of tea either, but if I do:#include <math.h>on the root.exe prompt, then it makes the fabs call available to TTreeFormula. My guess is that CINT has its own fabs defined somewhere.

I’ll ping Philippe.

Cheers,
Wim

Hi,

from Philippe:[quote]fabs is one of the ‘odd-ball’ function in CINT as it is supported on
the prompt by having the parser known about it directly but without
entering it into the reflection database (So TFormula can see it).

“math.h” pulls in stdfunc.dll which provides the meta-data:

root [8] .function > res01
root [9] .! grep abs res01
stdfunc.dll -1:-1 0 public: int abs(int n);
stdfunc.dll -1:-1 0 public: double fabs(double z);
stdfunc.dll -1:-1 0 public: long labs(long n);[/quote]Cheers,
Wim

Hi Wim,

thanks, that is very useful information. I had a look into $ROOTSYS/cint/cint/lib/stdstrct/stdfunc.h which lists tons of other useful functions (also with names much shorter than e.g. their TMath twins). I think I will enjoy working with them for some applications. I just have to keep myself from thinking too hard about “if I include a header inside the interpreter TTreeFormula strings suddenly are parsed differently”.

Thanks,

Benjamin

See here: [url]Fabs and abs

[quote]I just have to keep myself from thinking too hard about “if I include a header inside the interpreter TTreeFormula strings suddenly are parsed differently”.[/quote]That one is actually easy. TTreeFormula’s parsing is tightly couple with the interpreter and it does not know any function (ok, also no functions) or classes unless the interpreter knows about it (humm … for classes, this is actually unless core/meta knows about it, but core/meta knows about the class the interpreter knows about).

Cheers,
Philippe.

[quote=“pcanal”]TTreeFormula’s
parsing is tightly couple with the interpreter and it does not know any
function (ok, also no functions) or classes unless the interpreter knows about
it (humm … for classes, this is actually unless core/meta knows about it, but
core/meta knows about the class the interpreter knows about).
[/quote]
Yes, I realized there’s a tight coupling with the interpreter when including
math.h didn’t allow e.g. fabs in TTreeFormulas in compiled code executed outside of
CINT (kinda obvious since CINT’s math.h is really a special CINT dll and not
the C header).

So how can PyROOT (or me in compiled code) make these functions available
easily? I blindly tried linking against libMathCore, libMathMore or libCINT
hoping it would automagically pull in the definition, but the formula still
couldn’t be parsed. Is manually linking against
cint/cint/include/stdcxxfunc.so.5 the only possible way?

Of course none of this is a serious problem, I am just curious.

Cheers,

Benjamin

Hi Ben,

You can always do:gROOT->ProcessLine("#include <math.h>");

Cheers,
Philippe.