-
Notifications
You must be signed in to change notification settings - Fork 1.4k
Description
- Checked for duplicates
Describe the bug
When importing data from a TTree, I specify a set of RooRealVars that tell RooFit which branches I want to pull data from. It is my understanding that if a value is less than the bounds of a particular RooRealVar, it is excluded. This is not in fact the case. One issue stems from this method or this line in the code, where I found that RooFit actually adds 1e-6 to either side of that comparison. I couldn't find this documented anywhere, and I'm not really sure why it's there to begin with, but maybe someone here with more knowledge of the code has a reason for why this is the way it is. This is less of a bug and more a lack of documentation. I would also consider the second implementation of inRange here troubling, as it adds an epsilon = 1e-8 * fabs(val) to the comparison (and switches from < to <=. Again, maybe this is intentional, but these will certainly give different results in edge cases. The assignment operator uses the first one.
Expected behavior
I expect the following behavior:
RooRealVar t1("t1", "Some variable", 0.001, 1.0);
t1 = 0.000998;
cout << t1.getVal() << endl;
// returns 0.001 since it's outside the range specified
t1 = 0.000999;
cout << t1.getVal() << endl;
// should also return 0.001, since it's outside the range
To Reproduce
RooRealVar t1("t1", "Some variable", 0.001, 1.0);
t1 = 0.000999;
cout << t1.getVal() << endl;
// returns 0.000999
// lest this be attributed to some floating point arithmetic:
t1 = 0.0009990000;
cout << t1.getVal() << endl;
// yields 0.000999 but
t1 = 0.0009999999;
cout << t1.getVal() << endl;
// yields 0.0001 as expected
Setup
- ROOT version: 6.26/10
- Ubuntu 22.04 (but the result is independent of OS as far as I can tell, I've tried it on MacOS and RedHat 7)
- Built from source
Additional context
The reason this is important for my work is that I am importing data from a TTree, running sPlot to generate weights, the writing a new TTree with the sPlot weights as a new branch. The new tree will have fewer entries than the old one, since the import step excludes values which are out of range. In practice, some values which C++ comparisons would call out of range make it through RooFit's comparison, which causes a mismatch between the expected number of events written and what is actually written. This mismatch causes the number of events with weights to be larger than the number of events to be written, so at some point in my writing loop, an event is skipped by a C++ comparison but not by RooFit, so the weights become out of sync.