[RF] Make margin in RooAbsRealLValue::inRange() zero by default
#11999
Conversation
guitargeek
requested review from
bellenot,
hageboeck and
lmoneta
as code owners
guitargeek
force-pushed
the
rangecheck_1
branch
from
4f3802a to
7accc3f
Compare
|
Starting build on |
|
Build failed on mac12/noimt. Errors:
Warnings:
|
|
Build failed on windows10/cxx14. Errors:
|
guitargeek
force-pushed
the
rangecheck_1
branch
from
7accc3f to
31dca45
Compare
|
Starting build on |
|
Build failed on windows10/cxx14. Errors:
|
|
Build failed on mac11/cxx14. Errors:
|
guitargeek
force-pushed
the
rangecheck_1
branch
from
31dca45 to
fe09949
Compare
|
Starting build on |
guitargeek
force-pushed
the
rangecheck_1
branch
from
fe09949 to
654b00c
Compare
|
Starting build on |
guitargeek
changed the title
RooAbsRealLValue::inRange() overloads consistent RooAbsRealLValue::inRange() zero by default
The different overloads of `RooAbsRealLValue::inRange()` implemented different tolerances when checking if a value `x` falls inside a specific range. Some overloads checked if the interval `[x - 1e-6, x + 1e6]` is overlapping with the range, an other overload checked if the interval `[x - 1e-8*x, x + 1e8*x]` is overlapping. It's better is this is done consistently and predictably so this commit suggests to leave out these epsilon margins that were never documented. For backwards compatibility, one can set a custom relative or absolute epsilon via the `RooNumber` interface.
guitargeek
force-pushed
the
rangecheck_1
branch
from
654b00c to
307d95a
Compare
|
Starting build on |
lmoneta
left a comment
lmoneta
left a comment
There was a problem hiding this comment.
LGTM!
I have a comment on RooNumber::_Infinity.
I think every compiler has numeric_limits now, so one can remove the ifdef, which is not defined.
If you don't want to use infinity (I don't think there reasons not to do this), then I think is better using std::numeric_limits<double>::max(). 1.E30 is std::numeric_limits<float>::max().
|
Okay! I will try out this change with infinity later later |
3 participants
The different overloads of
RooAbsRealLValue::inRange()implementeddifferent tolerances when checking if a value
xfalls inside aspecific range. Some overloads checked if the interval
[x - 1e-6, x + 1e6]is overlapping with the range, an other overloadchecked if the interval
[x - 1e-8*x, x + 1e8*x]is overlapping.It's better is this is done consistently and predictably so this commit
suggests to leave out these epsilon margins that were never documented.
For backwards compatibility, one can set a custom relative or absolute
epsilon via the
RooNumberinterface.Also, the checks if the range limits are
RooNumber::isInfinite()wereremoved. They were mathematically redundant, since in RooFit, +/-
infinity is simply defined as +/-1e30.
This PR fixes some corner cases in which you get paradox results from rage checks, like in this example:
RooRealVar x{"x", "x", 1e-6, 2e-6}; RooRealVar y{"y", "y", 1e30, 1e30}; std::cout << x.inRange(0.0, nullptr) << std::endl; std::cout << y.inRange(0.0, nullptr) << std::endl; // both checks will return true without this PR!