[comp.os.vms] Bafflement

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