Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Highlighted
Beginner
11 Views

Handling NaN

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
Highlighted
Black Belt
11 Views

I think that you should

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
Highlighted
Valued Contributor II
11 Views

But the behaviour that you

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
Highlighted
Black Belt
11 Views

How do the NaNs occur in the

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
Highlighted
11 Views

a = a + b

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

Jim Dempsey

0 Kudos
Highlighted
Beginner
11 Views

Suppose A=NaN. I noticed that

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
Highlighted
11 Views

IIRC, CVF had /fpe:0 as its

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
Highlighted
Black Belt
11 Views

Quote:Kristan R. wrote:

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