Community
cancel
Showing results for
Did you mean:
Highlighted
Beginner
32 Views

## Release Mode vs Debug Mode: Different value stored in variable

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.

Tags (1)
7 Replies
Highlighted
Beginner
32 Views

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

Highlighted
New Contributor II
32 Views

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.

Highlighted
Beginner
32 Views

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```

```     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

Highlighted
Black Belt
32 Views

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., log10(253) = 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.

Highlighted
Black Belt Retired Employee
32 Views

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

Highlighted
New Contributor II
32 Views

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```

Highlighted
New Contributor II
32 Views

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.