[comp.os.vms] Solution To Problem Causing Bashing Of Head...

CLAYTON@XRT.UPENN.EDU.UUCP (09/19/87)

Information From TSO Financial - The Saga Continues...
Chapter 22 - September 19, 1987

The following problem was sent on why the answers where not as expected
when using Fortran or Pascal.

	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
	
The answer to this is singular in nature but there are additional caviats that
need to be answered. The reason for getting the value of B to be 3 instead of
the 2 that would be expected is that the values being used are larger then 
can be defined (correctly) in REAL*4, which is the default. By changing the 
REAL statement to REAL*8 then the program works as expected.

The caviat is to not MIX mode on the various statements if at all possible. You
could fall victim to a rounding error by the compiler should happen to have the
right (wrong) value specified. The impact of this is to put decimal points after
the numbers that you are comparing to and performing math with. Now some will
look at the machine code, as I did, and say that there will be no savings in 
time since conversions to floating point values is done by the Fortran compiler,
and they would be right. I have to ask about the rest of the languages and if 
they are as smart (?) as the Fortran compiler on VAX.

Hope this helps stop the bashing. :-)
	
Paul D. Clayton - Manager Of Systems
TSO Financial - Horsham, Pa. USA
Address - CLAYTON%XRT@CIS.UPENN.EDU