Variables and Functions in floating point calculations

[Rusty_Zarecor]

I have been working on optimizing some code and I my issue is a FORTRAN function of a constant in a loop.  My issue is that my answers are different when I pull the FUNCTION out of the loop and assign it to a variable vs. leaving the FUNCTION in the loop.  My code is very iterative and the answers vary out in the 7th decimal place.   Example:

      do 10 i=1, 11

          ans = x+y*funcf(z)

10 continue

vs

  fz = funcf(z)

  do 10 i=1,11

   ans = x+y*fz

10 continue

The Function funcf is defined as a Real*4 as are all the other variables.  My question is:  Does the FORTRAN compiler convert all the variables to double precision while it is doing the calculation and then assign it to the variable ans?  And if this is true it probably cannot do that for the function and as a result the answers would vary by a small amount?

Thanks

[Ron_Green]

there could be many things going on here.  First, you didn't mention what compiler version and what options you're using.  That matters, a lot!

at O2 and above the compiler may completely optimize out the loop - look at the variables and functions inside the loop, there is nothing that depends on the loop index.  Couldn't the compiler decide to do this, completely eliminate the loop:

  ans = x + y*func(z) 

same result, right?  Nothing in this expression that is loop dependent so it can be hoisted out, leaving an empty loop that gets optimized away.

if all the variables are single precision they will stay single precision - there is no need to convert to double anywhere if these are all REAL (kind=4). 

Every now and then we see people trying to experiment with either timing or precision and getting tripped up by optimizations.  What is it exactly that you're trying to test or do?  If you're playing with precision, have you read about and tried -fp-model option?  Like -fp-model precise is a good test.  Please read this if numerics is your interest:  http://software.intel.com/sites/default/files/article/299022/fp-control-2013-03.pdf

ron

[m_sulc]

with REAL*4, the intrinsic function EPSILON returns 1.1920929E-07, so I think that the discrepancy on the 7th digit can be safely attributed to the round-off errors the extent of which can be different in the above mentioned scenarios since the compiler might produce different code dependening (not only) on the optimization level and various other flags from the -fp-... family