-
Notifications
You must be signed in to change notification settings - Fork 572
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
Made nan's quiet to hide FPEs #4180
Conversation
This also brings |
I still don't understand the point of using a quiet_nan vs a signaling nan, if the point of setting something to NaN is that you catch errors, wouldn't you want to catch those errors when they start? Quiet nan seems useful for a flag, but since you can do math and the quiet bit propagates to all the other nans it seems somewhat pointless. I do understand that you can throw nan's in algorithms in a harmless way, then you might wanna use quiet, but I think that caching the FPE handling flags, handling the case where you go NaN and then resetting them after is a better way to handle this case. |
I agree with @bathmatt. Switching to the signaling NaN allowed an application to catch a range of errors in a Trilinos package that were generating NaNs quietly before. It seems that when an algorithm wants to use NaNs in a quiet way, this should be done explicitly. However, it appears though that the Teuchos::ScalarTraits::nan() implementation is being used both when an algorithm wants a harmless NaN and to indicate there's something wrong (e.g. in the Teuchos::ScalarTraits::squareroot() implementation). How is downstream application supposed to distinguish between these two cases? |
There's no way to distinguish. You just have to know that an algorithm might generate harmless NaNs, and turn off signaling while that algorithm runs. I like IEEE 754 and I want users to have the option to enable signaling NaNs, but I think changing Teuchos (nearly the most upstream package in Trilinos) without a lot of application testing was premature. |
@mhoemmen Would a possible compromise be to add a compile time option to switch between quiet and signaling NaNs? This option would default to the quiet NaN case and and then an application could decide whether or not to turn it on. |
I'm not a fan of adding Still More Compile-Time Options. No one will ever test the signaling one, then someone will try it and it won't compile, exactly at the time when you needed it to. If you decide to do it, note that the option would need to control both Teuchos::ScalarTraits and Kokkos::ArithTraits. Right now, you've only been looking at ScalarTraits. |
Status Flag 'Pre-Test Inspection' - Auto Inspected - Inspection Is Not Necessary for this Pull Request. |
Status Flag 'Pull Request AutoTester' - Testing Jenkins Projects: Pull Request Auto Testing STARTING (click to expand)Build InformationTest Name: Trilinos_pullrequest_gcc_4.8.4
Jenkins Parameters
Build InformationTest Name: Trilinos_pullrequest_intel_17.0.1
Jenkins Parameters
Build InformationTest Name: Trilinos_pullrequest_gcc_4.9.3_SERIAL
Jenkins Parameters
Build InformationTest Name: Trilinos_pullrequest_gcc_7.2.0
Jenkins Parameters
Using Repos:
Pull Request Author: bathmatt |
Status Flag 'Pull Request AutoTester' - Jenkins Testing: all Jobs PASSED Pull Request Auto Testing has PASSED (click to expand)Build InformationTest Name: Trilinos_pullrequest_gcc_4.8.4
Jenkins Parameters
Build InformationTest Name: Trilinos_pullrequest_intel_17.0.1
Jenkins Parameters
Build InformationTest Name: Trilinos_pullrequest_gcc_4.9.3_SERIAL
Jenkins Parameters
Build InformationTest Name: Trilinos_pullrequest_gcc_7.2.0
Jenkins Parameters
|
Status Flag 'Pre-Merge Inspection' - SUCCESS: The last commit to this Pull Request has been INSPECTED AND APPROVED by [ mhoemmen ]! |
Status Flag 'Pull Request AutoTester' - Pull Request will be Automerged |
Merge on Pull Request# 4180: IS A SUCCESS - Pull Request successfully merged |
make nan's quiet