Repository navigation
[RF] Don't wrap jointly normalized RooProdPdf factors for normalization - #24039
Open
guitargeek wants to merge 1 commit into
Open
guitargeek wants to merge 1 commit into
guitargeek wants to merge 1 commit into
Conversation
Factors of a RooProdPdf with overlapping normalization observables are
normalized together by a RooGenProdProj. RooProdPdf::compileForNormSet()
now creates the computation graph of the RooFixedProdPdf from a shallow
clone of the product where these factors are unwrapped from their
RooNormalizedPdf, so the RooGenProdProj integrates the unnormalized pdfs
like the scalar evaluation. The RooFixedProdPdf still forwards
analytical integrals to the product with the wrapped pdfs: with the
unwrapped ones, these integrals would not match its normalized value,
which breaks nested products.
This fixes two problems with the wrapped pdfs:
* The RooGenProdProj clones its pdfs, and the clone of a
RooNormalizedPdf owns a copy of its normalization integral, which
the RooFit::Evaluator doesn't keep up to date. If the normalization
depends on an observable, for example for a pdf conditional on it,
the likelihood in the new test was wrong by 36 %.
* Integrals of normalized pdfs are smaller, so the absolute tolerance
of the numerical integration costs more precision. For the
rf305_condcorrprod model of the HS3 test suite, the relative error
of 1e-6 exceeded the tolerance of the suite.
The new test requires agreement with the scalar evaluation to 1e-10.
🤖 Done with the help of AI
Test Results 22 files 22 suites 3d 15h 17m 25s ⏱️ For more details on these failures, see this check. Results for commit 550a9bd. |
This branch has not been deployed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Part of the final CPU backend bugfixes before the legacy NLL backend removal
Factors of a RooProdPdf with overlapping normalization observables are normalized together by a RooGenProdProj. RooProdPdf::compileForNormSet() now creates the computation graph of the RooFixedProdPdf from a shallow clone of the product where these factors are unwrapped from their RooNormalizedPdf, so the RooGenProdProj integrates the unnormalized pdfs like the scalar evaluation. The RooFixedProdPdf still forwards analytical integrals to the product with the wrapped pdfs: with the unwrapped ones, these integrals would not match its normalized value, which breaks nested products.
This fixes two problems with the wrapped pdfs:
The RooGenProdProj clones its pdfs, and the clone of a RooNormalizedPdf owns a copy of its normalization integral, which the RooFit::Evaluator doesn't keep up to date. If the normalization depends on an observable, for example for a pdf conditional on it, the likelihood in the new test was wrong by 36 %.
Integrals of normalized pdfs are smaller, so the absolute tolerance of the numerical integration costs more precision. For the rf305_condcorrprod model of the HS3 test suite, the relative error of 1e-6 exceeded the tolerance of the suite.
The new test requires agreement with the scalar evaluation to 1e-10.
🤖 Done with the help of AI