Release Mode vs Debug Mode: Different value stored in variable

[Morgan__Kent]

I have the following line of code:

lumsum = lumsum*expoq/expot*.000255*base

All the variables are double precision and I checked to make sure that all the variables on the left side have EXACTLY the same respective values in Release mode and Debug mode.  Before this line of code, if I print the expression on the left side of the equation, BOTH modes print a value of 13.404518622426956.  However, under this line of code, if I print "lumsum", Release mode prints a value of 13.404518622426954 while Debug mode prints a value of 13.404518622426956.

Does anyone know why this is happening?  Is there a way to fix this so that both modes will ultimately store the exact same value in "lumsum"?

Thanks.

[Morgan__Kent]

Sorry, I meant to say "on the RIGHT side of the equation".

[JohnNichols]

If your number represented the distance from NY to Boston -- the difference is 0.1 nano metres,  -- Intel can measure 0.1 nm but it is not really a number of great concern - we have an accelerometer that can measure nm -- but only for less than 1/2000th of a second

These numbers cannot be input into EXCEL at that level of precision 

I would say give up.

[Sampson__Andrew]

I would agree with John above. I have always operated under the assumption that the last digit in floating point variables was not to be trusted. When I learned FORTRAN, by Los Alamos Physicist Mentor taught me that last value is dependent on many variables and isn't "real" and depends on CPU and compiler behavior. Hence why they are different with different compiler options.

In application of this principle, when comparing two floating point values for equality, I always ask if the difference is above some threshold, instead of using the == comparison.

if(abs(val1-val2) < 1.d-12)then 
  they are effectively equal 
endif

instead of:

     if(val1==val2)then
       they are equal
     endif

Your values are identical. I never trust the last number in floating point precision. Those are my thoughts, at least.

Best Regards,

Andrew

[mecej4]

Morgan, Kent wrote:
 Is there a way to fix this so that both modes will ultimately store the exact same value in "lumsum"?

There is nothing to fix. You are looking at two strings that are both approximate decimal representations of internal values that have 53 significant bits, i.e., log₁₀(2⁵³) = 15.xx decimal digits. The two numbers that you regard as different are identical in the first 16 digits. Only the 17th digits differ. If you viewed the two numbers in their internal representations, they would probably turn out to be identical, so the "difference" that perturbs you may also be an artifact of the binary-to-decimal conversion process(es) used.

[Steve_Lionel]

I will also comment that .000255 in your expression is single-precision and is not as precise as it would be if you had written .000255D0. Here's the difference in single and double precision:

  0.25499999173916876E-03
  0.25500000000000002E-03

[JohnNichols]

The difference between these two numbers on the NY to Boston standard is 16541 nm or if the original error represents a standard Roman legion step your error would be 4.1% of the way across the USA. 

I suggest you put all constants in one place -accurately

Module Base

    INTEGER, PARAMETER :: dp = selected_real_kind(15, 307)

    INTEGER, PARAMETER :: sw = 2                    !   Output file
    INTEGER, PARAMETER :: srA = 15                  !   output.txt file
    INTEGER, PARAMETER :: srB = 16                  !   output.txt file
    INTEGER, PARAMETER :: st = 14
    INTEGER, PARAMETER :: sCAD = 12
    INTEGER, PARAMETER :: sa = 3                    !   Output file
    INTEGER, PARAMETER :: smWrite = 4
    INTEGER, PARAMETER :: si = 1
    Integer, parameter :: slog = 9                  !   Log file
    Integer, parameter :: nta = 200                  !   Log file
    Integer, parameter :: outNode = 63                  !   Log file
    Integer, parameter :: inNode = 0                  !   Log file
    integer, parameter :: nt1 = 2000
    integer, parameter :: mt1 = 2000        !   Number of members
    integer, parameter :: mn1 = 2
    integer, parameter :: ml1 = 3
    integer, parameter :: ml2 = 4
    integer, parameter :: ml30 = 9000
	integer, parameter :: limit = 9000

    REAL (KIND=dp), PARAMETER :: gr = 9.806_DP, pi = 3.14159265_DP  !   Standard parameters
    REAL (KIND=dp), PARAMETER :: delta = 0.001_DP     !   Error number of checking for zero
    REAL (KIND=dp), PARAMETER :: deltafreq = 0.00001_DP     !   Error number of checking for zero
    REAL (KIND=dp), PARAMETER :: ZERO = 0.0_DP
    REAL (KIND=dp), PARAMETER :: ONE = 1.0_DP
    REAL (KIND=dp), PARAMETER :: TWO = 2.0_DP
    REAL (KIND=dp), PARAMETER :: THREE = 3.0_DP
    REAL (KIND=dp), PARAMETER :: THIRTY = 30.0_DP
    REAL (KIND=dp), PARAMETER :: FOUR = 4.0_DP
    REAL (KIND=dp), PARAMETER :: SIX = 6.0_DP
    REAL (KIND=dp), PARAMETER :: TWELVE = 12.0_DP
    REAL (KIND=dp), PARAMETER :: PointFIVE = 0.5_DP
    REAL (KIND=dp), PARAMETER :: PointTWOFIVE = 0.25_DP
    REAL (KIND=dp), PARAMETER :: OneHundred = 1.0_DP
    REAL (KIND=dp), PARAMETER :: DeltaFr = 15000000.0_DP
    REAL (KIND=dp), PARAMETER :: FTR = 1.0_DP
    REAL (KIND=dp), PARAMETER :: FTRA = 100.0_DP
    REAL (KIND=dp), PARAMETER :: SMALLMASS = 0.0001_DP
    REAL (KIND=dp), PARAMETER :: SMALLMASS1 = 0.0000000000000000001_DP
    REAL (KIND=dp), PARAMETER :: SMALLNUMBER = 0.0001_DP
    REAL (KIND=dp), PARAMETER :: SMALLNUMBER1 = 0.0000000061_DP

[JohnNichols]

Of course it was said much more elegantly in the Bible Matthew 7:4 - but the idea is the same. 

PS -- Dear All -- this is a weekend test.