Rounding Question

[Michael8]

Hello:

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

double precision :: temp
temp = 0.0625write(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?

Thanks.
Michael

[Steven_L_Intel1]

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

[Steven_L_Intel1]

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.

[Michael8]

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.

Thanks.
Michael

[g_f_thomas]

What if you write temp as

temp =0.0625d0

?

Gerry

[Steven_L_Intel1]

The ZIP is password-protected.

[michael84]

The password is "ssa".

[g_f_thomas]

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.

Gerry

[Steven_L_Intel1]

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

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

[TimP]

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.

[g_f_thomas]

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

[Steven_L_Intel1]

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

[Michael8]

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.)

Thanks.
Michael

[Steven_L_Intel1]

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.

[Michael8]

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.

Michael

[Steven_L_Intel1]

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

[Michael8]

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.

Thanks
Michael

[Steven_L_Intel1]

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

[g_f_thomas]

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

Gerry

[Michael8]

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.

Michael

[Steven_L_Intel1]

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