Rounding Question

Rounding Question


I have a simple program that consists of the following 3 lines of code:

double precision :: temp

temp = 0.0625

write(6, '(F10.3)') temp

When I compile (using compiler version 10.1.014) the code in Debug mode and run it,it writes out the number 0.062. But when I use Release mode I get a result of 0.063.

Why is there a difference?


33 posts / 0 new
Last post
For more complete information about compiler optimizations, see our Optimization Notice.

I can't reproduce this. I get 0.063 in both cases.

Retired 12/31/2016

Curiously, I might have expected .062 as this matches the IEEE "round to even" rule. How the F format rounds is unspecified by Fortran 95. Fortran 2003 allows user control over rounding, but the default choice is left implementation-dependent. Intel Fortran does not yet support the user-controlled rounding features.

Retired 12/31/2016

Thanks for looking into this. That's interesting that you can't reproduce it. I'm attaching a zip file with the solution file, project file, and source code file.

This zip file comes form my co-worker's computer, and he is the one actually running version 10.1.014. I'm actually running 9.1.039. The results I posted in my first post were really from my run. We noticed for him, though, the results are flipped (0.062 in Release mode and 0.063 in Debug mode).

I'm curious to see if you can reproduce the problem with the attached zip file.



Downloadapplication/zip test_0625.zip1.37 KB

What if you write temp as

temp =0.0625d0



The ZIP is password-protected.

Retired 12/31/2016

The password is "ssa".

Really? I didn't know it had password protection until Steve told me, I'm not familiar enough with my zip to know how to password an archive. But if' 'ssa' works then good but I appear to be able to expand it no problem and without being privy to the pswd.


Could you actually extract the files, Gerry? I couldn't.

I get .063 in both Debug and Release modes with this project.

Retired 12/31/2016

IEEE round to even default, and Fortran user controlled rounding, apply
only in binary mode, as far as I can tell from references. In the case
posed, 0.0625 is representable exactly in both single (as specified)
and double precision, so the range of possible "problems" is limited,
even though this small case involves conversion from decimal to single
precision binary, to double precision binary, and then to decimal
again. The issue of passing through single precision representation
could be removed, as previously suggested, but that will make no
difference here, since no roundoff is involved.
The question asked pertains to conversion from binary to
decimal, without enough places allowed to recover the exact decimal
value. If you allow enough places, the IEEE rules require
0.06250000... to be displayed, with a tolerance of plus/minus
0.47*temp*epsilon(temp), if I remember correctly.

Steve, I think we have cossed threads here. Yes, when I click on the link I can open it on your server without downloading it. Did the 'ssa' password work? I'll rezip it with a different zip tool and see if that works.


Gerry, I was referring to Michael's zip, not yours.

Retired 12/31/2016

Sorry about the password. When my co-worker (Michael84) emailed the zip file to me, he had to password protect it to get it through our email system filter. Then I forgot to take off the encryption before posting it.

Gerry, I forgot the "d0" at the end, but adding this makes no dfifference. As Tim pointed out, there's no rounding issue here becuase 0.0625 should be exactly representable as either single precision of double precision.

Thanks everyone for looking into this. I'm not sure why you can't reproduce it.

I noticed also that similar inconsistencies occur with other numbers that are negative powers of 2, such as 0.03125 and 0.015625. But it didn't happen with 0.5, 0.25, or 0.125. (These I've tested on my computer, using version 9.1.039.)


Either .062 or .063 is an acceptable answer. It all depends on what rounding method is in use. In IEEE floating arithmetic, if a value is exactly halfway between two representable values, the rounding is done so that the last digit is even and not odd. So .062 would follw for that. On VAX systems, as a counter-example, rounding is "away from zero", so .063 would be correct.

The only place that the Fortran standard explicitly calls out the rounding method is for the NINT intrinsic, in which rounding away from zero is specified. I had thought that the compiler used IEEE rules for formatted output, so I don't quite understand what is happening here. I'll ask the developers familiar with the code to see what should be expected.

Retired 12/31/2016

I agree that either 0.062 or 0.063 is acceptable -- I don't really care which onegets output. I'm just trying to figure out why Release and Debug mode are giving different answers. It's making some of our validation more painful.

Furthermore, although I can't reproduce it today, yesterday I was even getting inconsistent results justwithin Debug mode depending on whether or not I had an extra, unrelated, write statement in my program.

Thanks for checking with the developers on this matter.


Sounds as if you may have an uninitialized variable or out of bounds array access in your program.

Retired 12/31/2016

Actually,I wasusing that test program, exactly as I sent it to you. So there are no uninitialized variables or arrays out of bounds. The only thing I added was an extra write statement (that printed out the variable with more precision), and this caused the results of the first write statement to change.


I found a way to reproduce the problem. If I link /libs:dll, I get .062. Let me look into this some more.

Retired 12/31/2016

Default floating point speculation goes from safe to fast in going from debug to release configurations. Check what happens if they are the same.


Thanks for your suggestion, Gerry.

I see, using the Visual Studio IDE, that the floating point speculation changes between Debug and Release; however it is grayed out and does not let me change it. Looking at the "Command Line" (in the IDE Propery Pages), there appears to be no Qfp option at all in either configuration.


I would be very surprised if any option related to generated code affected this - it's all inside the run-time library.

Retired 12/31/2016


I would just like to add that we have come across this issue when carefully monitoring changes due to the compiler upgrades and visual studio. I can reproduce this error for 0.0625 when using the IVF9.1 integration with VS2003 and switching the debug/optimize modes. However, this doesn't seem to happen when using VS 2005.

Program Test_Rounding
! Purpose: To test rounding in the print-out.
Implicit None
Integer, Parameter :: DOUBLE = kind(1.0d0)
Real(DOUBLE) :: a
a = 0.0625
Write(*,"(A,F7.3)") "a=", a
End Program Test_Rounding

This gives:

(1) VS2003, ifort /O2 => 0.062

(2) VS2003, ifort /debug:full => 0.063

(3) VS2005, ifort /O2 => 0.063

(4) VS2005, ifort /debug:full => 0.063


Interesting. My test was using VS2005 which may be why I did not see the same results. When I get information from the developers as to what is causing the difference I'll let you know.

Retired 12/31/2016


It might also be of interest to print out the Hex format of a as well as the SIZEOF(0.0625).

This would indicate if the anomaly were attributed to

a) The value of the literal 0.0625
b)The type of the literal as beingreal(4) or real(8)
c) If the anomaly is attributed to the write statement or "=" statement

Jim Dempsey

.0625 is exactly representable even in single precision. The difference, whatever it is, is internal to the run-time library ans not the compiled code.

Retired 12/31/2016


Thanks for pointing out that there is a difference between VS2003 and VS2005. As Steve suggested, that may have been why he was unable to replicate my results, as I was using VS2003. Even though he was eventually able to reproduce this type of inconsistency with some linker setting, it bothered me that he couldn't reproduce it exactly as-is based on the code I posted and him using the exact same compiler version.


When using VS2003, I can reproduce the difference by selecting the non-debug libraries and not changing any other options. So it really is a library difference. I will be VERY interested to learn why.

Retired 12/31/2016

Quoting - Steve Lionel (Intel)
When using VS2003, I can reproduce the difference by selecting the non-debug libraries and not changing any other options. So it really is a library difference. I will be VERY interested to learn why.


Sorry to bring back this old thread, but we're running into a very similar issue to this one again. Were you ever able to find out from the developers why there is a difference in rounding?


The issue is still open and I do not have a response from the engineers. I will ping them.

Retired 12/31/2016


we have a similar problem with rounding in the F-Format.
It doesn't round correctly.

We have tried various compiler-settings, but we got always the same (wrong) result.
We have written a simple code to demonstrate this:

program roundTest

real*4 rtemp

write(*,'(''rtemp: '', f5.1, f10.5)') rtemp, rtemp
write(*,'(''rtemp: '', f5.1, f10.5)') rtemp, rtemp

end program roundTest


rtemp: 6.2 6.25000
rtemp: 6.8 6.75000

Do you have any explanations or solutions?
What should we do?

Thanks a lot!
Sincerely, Alexandra and Zuzana

Alexandra and Zuzana,

The results you are seeing here are correct. The Fortran standard does not specify the method of rounding for F format, and our implementation follows the IEEE floating point "round to even" rule which says that if a value to be rounded is exactly halfway between two representable values, round such that the last digit is even.

If you explicitly want "round away from zero", add RC as a format edit descriptor or open the file with ROUND='COMPATIBLE'. Other choices are 'UP', 'DOWN', 'ZERO' and 'NEAREST'.

Retired 12/31/2016

Hi Steve,

thanks a lot for your quick answer! You were right with your proposal.
It works now properly.

However, we would like to point it out that the Intel-manual is not exhaustive.
We were looking forwards and backwards through
the documentation, but we were not able to find those assignments.

We have found it on the website of IBM.
under: Fortran...Control edit descriptors

Thanks again,
Alexandra and Zuzana

Yes - we have not yet documented all the Fortran 2003 features we support. We'll address that in the next major release.

Retired 12/31/2016

Leave a Comment

Please sign in to add a comment. Not a member? Join today