Community
cancel
Showing results for
Did you mean:
Highlighted
Beginner
78 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.

Tags (1)
7 Replies
Highlighted
Black Belt
78 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```

Highlighted
Valued Contributor II
78 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.

Highlighted
Black Belt
78 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.

Highlighted
Black Belt
78 Views

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

Jim Dempsey

Highlighted
Beginner
78 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?

Highlighted
Employee
78 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

Highlighted
Black Belt
78 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.