Turn on suggestions

Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.

Showing results for

- Intel Community
- Software Development Tools (Compilers, Debuggers, Profilers & Analyzers)
- Intel® Fortran Compiler
- Release Mode vs Debug Mode: Different value stored in variable

- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Mute
- Printer Friendly Page

Highlighted
##

Morgan__Kent

Beginner

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content

04-24-2020
12:55 PM

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.

7 Replies

Highlighted
##

Morgan__Kent

Beginner

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content

04-24-2020
01:21 PM

32 Views

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

Highlighted
##

JohnNichols

New Contributor II

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content

04-24-2020
02:19 PM

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

Sampson__Andrew

Beginner

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content

04-24-2020
02:56 PM

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

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

Highlighted
##

mecej4

Black Belt

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content

04-24-2020
03:59 PM

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., log_{10}(2^{53}) = 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
##

Steve_Lionel

Black Belt Retired Employee

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content

04-24-2020
04:35 PM

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

JohnNichols

New Contributor II

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content

04-25-2020
08:35 AM

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

JohnNichols

New Contributor II

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content

04-25-2020
08:42 AM

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.

For more complete information about compiler optimizations, see our Optimization Notice.