- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I built a model several years ago using Visual FORTRAN Standard Edition 6.0.A. I wanted to reuse the model again, but the software I am using now is Visual Studios 2015 with the Intel(R) Visual FORTRAN Compiler 16.0 [IA-32].
I noticed that NaN is being handled differently between the two compilers. For example, in the previous version, if b=0 and c=Nan, then a=b+c would result in a=0. However, in the current version, the same scenario would cause a=NaN.
Is there a way I could change the way NaN is handled in arithmetic expressions? I do not want variables to change to NaN if they are dependent on a variable that is NaN.
Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I think that you should provide example code and instructions for producing the behavior that you described.
I tried the following with CVF 6.6C (the only version that I have access to), Gfortran 6.3 and IFort 16. All gave the same results:
a b c NaN 0.000E+00 NaN
Here is the test code:
program xnan implicit none integer ic real a,b,c data ic/Z'7FF12345'/ ! b=0 c=transfer(ic,c) a=b+c write(*,'(A)')' a b c' write(*,'(3E11.3)')a,b,c end program xnan
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
But the behaviour that you object to is the behaviour that is required for operations with NaNs. The only way to prevent this from happening would be to prevent the occurrence of NaNs in the first place.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
How do the NaNs occur in the first place? I remain skeptical about replacing NaNs by zeros or treating NaNs in expressions as if they were zeros. If you can describe the necessity in detail, perhaps a more standard-conforming fix could be prescribed.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
a = a + b
if(isnan(a)) a = 0.0 ! What you wanted, but not mathematically correct
Jim Dempsey
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Suppose A=NaN. I noticed that the difference occurs in the following piece of code.
IF(A.LT.0.0)A = 0
The CVF6.6 assumes that NaN is less than 0 and gives A the value of 0. The iFort16, however, keeps A=NaN after the statement above. Is there a setting that could fix this difference?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
IIRC, CVF had /fpe:0 as its default, and ifort has /fpe:3 as its default.
You can try explicitly setting /fpe:0 on your program, and see if that helps.
--Lorri
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Kristan R. wrote:
Suppose A=NaN. I noticed that the difference occurs in the following piece of code.
IF(A.LT.0.0)A = 0
The CVF6.6 assumes that NaN is less than 0 and gives A the value of 0. The iFort16, however, keeps A=NaN after the statement above. Is there a setting that could fix this difference?
What you said is not true for the following code which, compiled and run with CVF 6.6C /fpe:3, gives "a = NaN". With /fpe:0, the program aborts with "forrtl: error (65): floating invalid".
program xnan implicit none integer ia real a data ia/Z'7FF12345'/ ! a=transfer(ia,a) ! a is a NaN here if(a < 0.0)a = 0.0 write(*,'(A,2x,ES10.3)')' a = ',a end program xnan
Even if you can show us code that does what you claim, you should not expect much sympathy for your wish to have a way of making the compiler produce erroneous results of your choosing.
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page