- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
Link Copied
10 Replies
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I don't see what VAX D float has to do with the program you posted. Can you elaborate?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
I'm assuming you're using Intel Fortran, which supports REAL(16). CVF doesn't.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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?
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?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
The programs I attached do not use Double precision, however the programs that I am converting use both single and double precision reals.
John
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Well, that is an OLD compiler. I tried it with 6.6C and got the same result for both programs.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Very true. I will make the recommendation to switch everything to double precision.
Thanks for the help Steve and Jugoslav.
John.
Thanks for the help Steve and Jugoslav.
John.
Reply
Topic Options
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page