PERAINO@GMUVAX.BITNET.UUCP (09/17/87)
I have been bashing my brains in on this one. Type in this program. Run it. The result will be; 3 33554436. Can someone out there please explain why? You might wonder where I came up with this program. I found that incrementing 33554432 by 1 does nothing! So I decided to see at what point the increment would take effect. An explanation of the output is needed; the three would mean that the increment took effect when b is 2. But it seems to increment the number by 4! This is also the case in pascal, where I originally tripped on this problem. Somebody PLEASE help me. program test real a,b a = 33554432 b = 1.0 100 if ((a .eq. 33554432) .and. (b .ne. 33554432)) then a = a + b b = b + 1 goto100 endif print*,int(b),int(a) end
winalski@psw.DEC.COM (Paul S. Winalski) (09/20/87)
You are being bitten by the precision limit for single-precision floating point (the VAX F-float data type). A FORTRAN variable declared simply REAL will be REAL*4, which VAX FORTRAN implements as F-floating. An F-floating number can have a very wide exponent range, but the mantissa only has six or so decimal digits of precision. Thus, when you say: a = 33554432 the resulting value of A will be 3.35544E+7, more or less. If you try adding 1.0 to this value, it winds up being a no-op because, when the two numbers are scaled for the addition, the 1.0 just falls off the end of the available precision. If you keep trying to add larger and larger values, eventually you hit one that is large enough to not scale off the low mantissa bit, and you will actually increment the number. In your case, this occurred at 4. The solution is to use double precision (D-float or G-float), which gives you 15 decimal digits of precision. Of course, the same problem occurs in Pascal because Pascal's single precision also uses F-float. --PSW