how to convert VAX D float

[schaferm]

conversion problem between VAX's floating point D to IEEEfloating point. Also attached is the test programs used that demonstrate the strange(presumably) parsing problem. The hex result is off by 2 bits. PPP isthe program for performing the calculationin a single equation, and QQQ is the program for performing each part ofthe calculation seperately.

Code:

	PROGRAM PPP
	IMPLICIT NONE
	REAL F,B3,GAMMAJ,E,RADIUS3,RADIUS2,D3

	F=12.
	B3=0.3974122
	GAMMAJ=0.
	E=-5.563771
	RADIUS3=2.236068
	RADIUS2=2.236068

	D3=-(F*(B3-GAMMAJ)+E)*RADIUS3/RADIUS2

	WRITE(*,100) D3
	WRITE(*,101) D3

	STOP 'PPP O.K'
100	FORMAT(F12.7)
101	FORMAT(1X,Z8)
	END

Code:

C QQQ.FOR
C DRG 13-0CT-2005
C
	PROGRAM QQQ
      IMPLICIT NONE
C
      REAL F,B3,GAMMAJ,E,RADIUS3,RADIUS2
      REAL A1,A2,A3,A4,A5,D3
C
      F=12.
      B3=0.3974122
      GAMMAJ=0.
      E=-5.563771
      RADIUS3=2.236068
      RADIUS2=2.236068
C
      A1=B3-GAMMAJ
      A2=A1*F
      A3=A2+E
      A4=A3*RADIUS3
      A5=A4/RADIUS2
      D3=-A5
C
      WRITE(*,100) A1
      WRITE(*,100) A2
      WRITE(*,100) A3
      WRITE(*,100) A4
      WRITE(*,100) A5
      WRITE(*,100) D3
C
      WRITE(*,101) A1
      WRITE(*,101) A2
      WRITE(*,101) A3
      WRITE(*,101) A4
      WRITE(*,101) A5
      WRITE(*,101) D3
C
      STOP 'QQQ O.K.'
C
  100 FORMAT(1X,F12.7)
  101 FORMAT(1X,Z8) 
      END

[Steven_L_Intel1]

I don't see what VAX D float has to do with the program you posted. Can you elaborate?

[johntaylor]

That was actually a chunk of an email I sent in. The programs were just demonstrating a loss of accuracy. The results on the VAX for each program were the same, #3F4B7998, and on Windows the result for seperated equations remained the same but for the calculation in a single equation the result was #3F4B799A.

I'm trying to migrate several programs from the VAX to Windows, and the results of floating point operations differ at first only in the last digit, but as more calculations occur that loss of accuracy affects up to the 4th last digit. The assumption is that this is either due to differences in parsing, or due to the change from D floating point to G floating point, and the resulting loss of bits in the mantissa.

Any suggestions would be appreciated.

[Steven_L_Intel1]

I don't see that you have any options other than to switch to quad precision. IEEE float does indeed have three fewer fraction bits than D_float and this will change the results. It isn't a "parsing" difference. If your computations really need the extra bits that D gave you, then do critical computations in REAL(16). Performance will be less.

I'm assuming you're using Intel Fortran, which supports REAL(16). CVF doesn't.

[Steven_L_Intel1]

Ok, now I'm beginning to understand.

First, VAX D float and IEEE double don't enter into it. Your programs are strictly single precision. Perhaps you want to use double precision instead?

Second, when I build and run these programs using a current version of Intel Visual Fortran, I get 3F4B7998 on both.

I do note that on IA-32, when using default compilation modes, the extended precision floating point registers can be used for some intermediate computations, and this can introduce small differences. Typically the IA-32 results are better than what you would get on VAX, because the single-precision computations are carried out in an extended double type and then rounded back to single on a store. But that does not seem to be the case here - even if I use /QxN to force use of SSE2 registers, the answer does not change.

What compiler and what specific version are you using?

[johntaylor]

I'm using Compaq Visual Fortran, version 6.6A, with default settings.

The programs I attached do not use Double precision, however the programs that I am converting use both single and double precision reals.

John

[Steven_L_Intel1]

Well, that is an OLD compiler. I tried it with 6.6C and got the same result for both programs.

[Jugoslav_Dujic]

In case you cannot find it (which is quite likely :-( ), CVF updates are here (until HP (re)moves them again).

Jugoslav

[johntaylor]

Thanks for the link. I had looked for updates a while ago, but apparently I did not look hard enough.

I updated, however I am strangely still having the same problem. I have been considering simply changing everything to double precision, however then I will still have a similar problem, while the results will be more accurate, I will be unable to compare them to the VAX results.

John.

[Steven_L_Intel1]

You're going to have problems with that anyway, as VAX float has other differences (rounding model in particular), plus math library differences. Clearly your program needs added precision if small errors build up quickly.

[johntaylor]

Very true. I will make the recommendation to switch everything to double precision.

Thanks for the help Steve and Jugoslav.

John.