You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When building ROOT with an LZMA library with with fast-math (the infectious kind), master and v6-34 gtest-tree-ntuple-v7-ntuple-types fails with:
/uscms/home/pcanal/root_working/code/v6-34-00-patches/tree/ntuple/v7/test/ntuple_types.cxx:1826: Failure
Expected equality of these values:
std::numeric_limits<float>::denorm_min()
Which is: 1.4012984643248171e-45
*d1
Which is: 0
/uscms/home/pcanal/root_working/code/v6-34-00-patches/tree/ntuple/v7/test/ntuple_types.cxx:1843: Failure
Expected equality of these values:
std::numeric_limits<float>::denorm_min()
Which is: 1.4012984643248171e-45
*d2Float
Which is: 0
This “light numerical instability detected by the test in RNTuple (near zero stored as strict zero).” turned out to be due to linking with (not even using) the LZMA library built as part of CMSSW. That libraries is built with fast math which sets the floating point unit to have the flat “FZ - Flush to zero” and “DAZ - Denormals are zeros” for (or course :() the whole process. However the flag affects only operations (conversion, arithmetic operations) but not direct usage, hence the apparent numerical instability (which changes with or without optimization). In particular directly printing or comparing to std::numeric_limits<float>::denorm_min() works but any other operations (including returning it through a not-inlined function) will zero out it.
The text was updated successfully, but these errors were encountered:
This is an odd and unfortunately not unknown behaviour. What is the bug in ROOT? What is the action that should be taken here? We need a concrete goal to achieve it and monitor progress along the way.
Ideally the test will be fixed to succeed even if "fast math" is enabled. If the behavior being tested and failing with "fast math" is essential to work as it is currently being checked in that test (and thus the test can not be changed) then we either need to find a way to make the feature work with "fast math" ... or we need to declare that RNTuple (or part thereof) does not work with "fast math" and add the proper documentation and/or checks in the 'right' places.
When building ROOT with an LZMA library with with fast-math (the infectious kind), master and v6-34
gtest-tree-ntuple-v7-ntuple-types
fails with:This “light numerical instability detected by the test in RNTuple (near zero stored as strict zero).” turned out to be due to linking with (not even using) the LZMA library built as part of CMSSW. That libraries is built with fast math which sets the floating point unit to have the flat “FZ - Flush to zero” and “DAZ - Denormals are zeros” for (or course :() the whole process. However the flag affects only operations (conversion, arithmetic operations) but not direct usage, hence the apparent numerical instability (which changes with or without optimization). In particular directly printing or comparing to
std::numeric_limits<float>::denorm_min()
works but any other operations (including returning it through a not-inlined function) will zero out it.The text was updated successfully, but these errors were encountered: