RooRealSumPdf inside a RooAddPdf and Generation of toys

Dear all
I am using a RooRealSumPdf with custom “fractions” definition and i enforce via RooFormulaVars that the sum of component fractions is always 1.
Doing so i can achieve a morphing of the shape scaling with negative and positive factors one of the sub-pdf of a RooRealSumPdf ensuring it still normalize to 1.

PDF_1 = frac1 * PDF1_1 + (1-frac1) * PDF1_2 + ( 1- frac1 -frac2) * PDF1_3

, and my morphing is achieved applying

frac1 --> ScaleFactor * frac1 

and when i do this i propagate

frac2 --> ( 1- ScaleFactor * frac1 ) * frac2Original
frac3 --> ( 1-  newFrac1 - newFrac2 ) 

Now this PDF morphed (PDF_1 --> PDF_1_Scaled (and another one where the same is done (PDF_1_Scaled), like this is used inside a RooAddPdf with fixed fractions assignments and passing n-1 coefficiencies :

FULL MODEL =   RooAddPdf( fracFull1[fix] , fracFull2[fix]  ,  PDF_1_Scaled , PDF_2_Scaled, OtherPDF) 

My question is if the scale factor goes negative for some reason in the scaled PDF morphed shapes,
Is this an issue when FULL_MODEL.Generate is executed?

( The question is a continuation of what i proposed as solution in RooSumPdf and RecursiveFraction with a scale factor on one of sub-components - #5 by jblomer ) with the difference that i encountered some bias in the Scale factor parameter when running toys and using RooAddPdf, since sometimes that parameter converged to 0 , the boundary. When that was left to go negative, but still using RooAddPdf i instead observed other weird behaviours.
So in practice, the use case i am doing of a negative yield is to achieve a morphing of the shape rather than actually fit its amount. Is this something safe one can achieve with RooRealSumPdf ?


Please read tips for efficient and successful posting and posting code

ROOT Version: Not Provided
Platform: Not Provided
Compiler: Not Provided

Is there anyone which can provide some feedback based on experience for toys using RooRealSumPdfs models?

Hi Renato,
sorry for the high latency, we need @moneta or @jonas for this one.


I am not sure I have understood the issue. Probably a running code example would be helpful to understand it better.
I think if one of the fractions of the RooRealSumPdf goes negative is probably not an issue, if the overall summer is not negative. Instead I think you cannot have negative components in a RooAddPdf.



Dear @moneta indeed from my checks and tests i didn’t see any issue. However there is a behaviour i really don’t undertand using forced RooFormulaVar to compute the coefficients to enforce the roorealsumpdf to integrate to 1. In practice it seems like in some very small fraction cases and when reaching 10-6 coefficient values, the pdf starts to throw messages about numerical issues and pdf sum of coefficient not being 1. Actually from the print it’s always 1.000x, so i suspect there might be some magic about float/double in rooformulaVar and roorealvar. I try to provide a reproducer of this.

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.