Intel® Fortran Compiler
Build applications that can scale for the future with optimized code designed for Intel® Xeon® and compatible processors.

Handling NaN

Kristan_R_
Beginner
1,442 Views

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.

0 Kudos
7 Replies
mecej4
Honored Contributor III
1,442 Views

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

 

0 Kudos
Arjen_Markus
Honored Contributor I
1,442 Views

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.

0 Kudos
mecej4
Honored Contributor III
1,442 Views

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.

0 Kudos
jimdempseyatthecove
Honored Contributor III
1,442 Views

a = a + b
if(isnan(a)) a = 0.0 ! What you wanted, but not mathematically correct

Jim Dempsey

0 Kudos
Kristan_R_
Beginner
1,442 Views

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?

0 Kudos
Lorri_M_Intel
Employee
1,442 Views

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

 

0 Kudos
mecej4
Honored Contributor III
1,442 Views

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.

0 Kudos
Reply