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

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.

What if you write temp as

temp =0.0625d0

?

Gerry

The ZIP is password-protected.

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.

Gerry

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

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

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

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

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.

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

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

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

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

Hi

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

Sincerely
Abhi

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.

Abhi,

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.

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.

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

Hi,

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

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

end program roundTest

Output:

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

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.
http://publib.boulder.ibm.com/infocenter/compbgpl/v9v111/index.jsp
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.