# Limit on operations in RooGenericPDF?

Hi all,

I’m trying to construct a RooGenericPDF which is basically the sum of a large number of polynomials that cannot be further reduced. The idea is that I’m making all possible combinations of the multiplication of Legendre polynomials in three variables. I came up with two possible approaches: (1) Create a RooProd from the multiplication of the polynomials (e.g. P_k(x)*P_l(y)*P_m(z)) and then I multiply the corresponding coefficients using a RooGenericPDF; (2) Create similarly the multiplication of the polynomials as a RooGenericPDF and then
step by step adding each of these equations.

The first approach seems to be working fine when I consider Legendre Polynomials with “l” up 6 (scriptROOTForum.py). However, if I use higher orders it seems that it cannot perform such calculation. The basic message that I receive when I try to generate some data from the PDF for l < 7 is the usual:

``` [#0] ERROR:Eval -- RooAbsReal::logEvalError(CombLeg) evaluation error, message : p.d.f value is less than zero (-0.000314), forcing value to zero ```
which is fine, since indeed sometimes this goes negative. However, when I use l > 6, the message became: “p.d.f value is Not-a-Number (nan), forcing value to zero”. My guess is that this is related to the number of operations allowed within the RooGenericPDF algorithm. Since the TFormula.SetMaxima() function seems to be deprecated in ROOT6, I tried with the older versions with this option and still didn’t make any difference. Any suggestion on how to solve this problem (if this is the cause)? Any other idea of why this is happening is very welcome!

Concerning the second script, the idea is to skip any issue with the TFormula limit (although this approach does not seems very efficient). However, for some reason the resulting PDF does not seems to preserve the appropriate coefficients of each of the polynomials. In other words, the generated data from this PDF seems to be basically the sum of polynomials with the same weight. Perhaps there is some intrinsic re-weight that I’m not aware of. So again any input is more than welcome!

To summarise: I’ve attached both scripts with the minimal version that I could think of. To run you just need to do something like:

`` python scriptROOTForum.py -p PTLegPol EtaLegPol nTracksLegPol -n 4  ``

or

`` python scriptROOTForum_subPDF.py -p PTLegPol EtaLegPol nTracksLegPol -n 4  ``

where the ‘-n’ option gives the degree of the Legendre polynomial to be consider (it will evaluate 0 up to n). Moreover, the coefficients that I use to multiply these equations were stored in a sqlite file that can be downloaded here (this is automatically accessed in the script):

Well, any of these options are fine by me, but I just need the possibility to calculate for higher order. Thanks a lot in advance for any help!

Cheers,
Rafael
scriptROOTForum_subPDF.py (8.11 KB)
scriptROOTForum.py (7.43 KB)

Hi,
I would avoid using a RooGenericPdf and eventually make yourself a class deriving from RooAbsPdf.

Best Regards

Lorenzo

Hi Lorenzo,

Thanks for the reply. As far as I understood from your reply, the idea to create my own class would be to avoid the use of the RooGenericPdf class, that basically inherits from a RooFormula that gets then evaluated. My follow-up question would be about which approach could I use to replace the RooFormula? Because in the end of the day I still need to sum a large number of polynomials which I naively would construct from the RooFormula. Do you have any suggestion to how to create this? Moreover, for my understanding, why the RooGenericPdf should be disfavoured in this case? In theory it should work for any expression, right? Thanks again for the input.

Cheers,
Rafael

Hi,

The RooGenericPDF uses the old TFormula *v5::TFormula) which is not based on Cling and it has some limitations. It might also be slower, making not very efficient.
For this reason I was advocating you to implement your class directly deriving from RooAbsPdf.

See the tutorial root.cern.ch/doc/master/rf104__ … ry_8C.html for doing this

Lorenzo

Hi,

Thanks a lot for the suggestion. Indeed it is working fine now and there is no longer any restriction in terms of the number of operations accepted.

Thanks!
Rafael