-
Notifications
You must be signed in to change notification settings - Fork 393
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Remove OrderedDicts etc except where empirically necessary #940
Remove OrderedDicts etc except where empirically necessary #940
Conversation
@kcormi - a very concrete check would be to run |
@nucleosynthesis, yes good suggestion. I tested this now, and there seems to be a difference in a RooProdPdf print out which I don't understand. I seem to get a same/similar one with the current main branch though. So I'm not sure if its actually related, or if I've just made a silly mistake in trying to test it. I'll need to investigate a little later, but I'll try to wrap this up soon so we can merge it. |
It seems in my tests that I still get a few lines of differences, even when using the fully ordered collections. It's always just a few lines with the RooProdPdfs, and the difference doesn't seem to be in the pdf itself, but that in one of the two lines printing the pdf out, there is also an error of the style
I'm not sure if it's really a problem, I suspect its not, but I'll try to see if I can track it down regardless. |
Here is the stack trace for where the
Indeed, the There is a check This is the reason why RooFit models are often magically fixed by writing the workspace to a file and reading it back: like this, all variables with the same name are de-duplicated, which is usually the intent of the model builder. So in this case, the ERROR is probably not an issue because you are importing the model to workspace anyway. While doing that, all variables are deduplicated. |
The `_sentry` is already filled when calling `evaluate()`, so no need to do that in the copy constructor. Doing so can actually leading to redundant calls to `_sentry.addVars(_coefList)`, resulting in the problem reported here: cms-analysis#940 (comment) ``` [#0] ERROR:InputArguments -- RooArgSet::checkForDup: ERROR argument with name CMS_vhbb_stats_TT_ZmmLoose7TeV is already in this set ```
Confirmed, the errors were harmless: we just tried to fill a collection with the same set of objects twice, and the second time you get an error instead of adding more elements. Can be avoided: #952 |
The `_sentry` is already filled when calling `evaluate()`, so no need to do that in the copy constructor. Doing so can actually leading to redundant calls to `_sentry.addVars(_coefList)`, resulting in the problem reported here: cms-analysis#940 (comment) ``` [#0] ERROR:InputArguments -- RooArgSet::checkForDup: ERROR argument with name CMS_vhbb_stats_TT_ZmmLoose7TeV is already in this set ```
Thanks @guitargeek -- I will merge this one. I need to double check #952 a little before merging it, but looks fine. |
The `_sentry` is already filled when calling `evaluate()`, so no need to do that in the copy constructor. Doing so can actually leading to redundant calls to `_sentry.addVars(_coefList)`, resulting in the problem reported here: cms-analysis#940 (comment) ``` [#0] ERROR:InputArguments -- RooArgSet::checkForDup: ERROR argument with name CMS_vhbb_stats_TT_ZmmLoose7TeV is already in this set ```
The `_sentry` is already filled when calling `evaluate()`, so no need to do that in the copy constructor. Doing so can actually leading to redundant calls to `_sentry.addVars(_coefList)`, resulting in the problem reported here: cms-analysis#940 (comment) ``` [#0] ERROR:InputArguments -- RooArgSet::checkForDup: ERROR argument with name CMS_vhbb_stats_TT_ZmmLoose7TeV is already in this set ```
It would be good to do a few more checks on this and take a closer look to make sure its what we want before merging, but this seems to preserve the creation order of all workspace objects, as discussed in #936.