Numerical discrepancies between MS Fortran 5.1 and Fortran Powerstation
Author 
Message 
Yvan #1 / 8

Numerical discrepancies between MS Fortran 5.1 and Fortran Powerstation
I transfered to a DLL using MS PowerStation 4.0 some old numerical routines that were part of a DOS program originally compiled with MS fortran 5.1. If left everything as is in the numerical part of the code. To test the new library, I execute the same calculations with both the original DOS program and the new DLL, and I found numerical discrepancies at the fourth and fifth significative digit. I ensured that the code for both versions is the same. I still can't find the reason, and I start to beleive that there may be differences in the intrinsic numerical functions used by Fortran of both versions. Someone knows about differences in numerical calculations between MS Fortran 5.1 and MS Powerstation that could explain these differences ??? Someone already got the same problem ??? Thanks in advance for any help. Yvan.

Wed, 18 Jun 1902 08:00:00 GMT 


N8T #2 / 8

Numerical discrepancies between MS Fortran 5.1 and Fortran Powerstation
Quote:
>I found numerical discrepancies >at the fourth and fifth significative digit. I ensured that the code for >both versions is the same. >I still can't find the reason, and I start to beleive that there may be >differences in the intrinsic numerical functions used by Fortran of both >versions. Someone knows about differences in numerical calculations >between MS Fortran 5.1 and MS Powerstation that could explain these >differences ??? >Someone already got the same problem ???
I don't know about those specific compilers, and I doubt that anyone would consider either as a reference standard. You might try running ELEFUNT (a TOMS testsuite), or CELEFUNT, whichever is appropriate, on these compilers. I assume you are running single precison. This discussion borders on flame bait, as some people consider the "correct" results to be the ones obtained by rounding off to single precision at every step (even inside the math functions). Other compilers, such as g77, don't normally invoke a single precision version of math functions, so the result is obtained by calculating in double precision (or better), followed by rounding to single precision. The latter approach looks much better when tested in ELEFUNT. Lahey lf90 and lf95, for example, choose the approach of rounding off each operation to single precision, whereby the EXP() function, for example, is rated by ELEFUNT as having only 20 bit precision in the worst cases. If one goes to the opposite extreme, the design of the x86 and 68xx family is such that there is no significant penalty involved in carrying extra precision far enough to get a rating of 52 bit precision for the double precision intrinsic functions. Tim Prince

Wed, 18 Jun 1902 08:00:00 GMT 


Catherine Rees La #3 / 8

Numerical discrepancies between MS Fortran 5.1 and Fortran Powerstation
Quote: >I transfered to a DLL using MS PowerStation 4.0 some old numerical routines >that were part of a DOS program originally compiled with MS Fortran 5.1. If >left everything as is in the numerical part of the code. >To test the new library, I execute the same calculations with both the >original DOS program and the new DLL, and I found numerical discrepancies >at the fourth and fifth significative digit. I ensured that the code for >both versions is the same. >I still can't find the reason, and I start to beleive that there may be >differences in the intrinsic numerical functions used by Fortran of both >versions. Someone knows about differences in numerical calculations >between MS Fortran 5.1 and MS Powerstation that could explain these >differences ??? >Someone already got the same problem ??? >Thanks in advance for any help. >Yvan.
Is there any chance that the code assumes variables are initialised to zero? I've found that in a DLL this is almost invariably not true, I've also seen a lot of DOS programs which expected it. It's possible this could cause numerical discrepancies, though in my experience these have normally been GPFs or wildly wrong values rather than in the decimal places. Might be worth a look, though. Catherine.  Catherine Rees Lay

Wed, 18 Jun 1902 08:00:00 GMT 


Herman D. Knob #4 / 8

Numerical discrepancies between MS Fortran 5.1 and Fortran Powerstation
Of course the elementary functions should be checked. But it's also true that numerical computation may be breaking down. It depends a lot on the algorithm itself. When someone at Penn State tells me that they switched operating systems or compilers and got different "answers" and ask which set of "answers" are correct, I usually tell them that neither should be trusted. Perturbing the input data (or constants) in an application may prove useful. If small perturbations of input or constants cause noticeable difference in results, then the numerical algorithms being used are at fault. For example, run the program: C==== Example 1: Dollars and Cents numeric breakdown. C On IBM 3090 Mainframe, A=100., X=0.01. yields P=39. C On PC's, A=10000., X=0.00001 yields P=68. C Reverse the rolls of A and X (e.g., A=0.00001, X=10000.) C and get correct result, P=1. using: C DOUBLE PRECISION P,A,X C doesn't change things much. C C NOTE: P is algebraically 1.0 for all A and X<>0. C Penn State University Center for Academic Computing C H. D. Knoble, August 1979. REAL P,A, X DO 1 I=1,99999 WRITE(6,*) 'Please enter A & X (or press CtrlC to Quit):' READ(5,*,END=99) A,X P=((A+X)**2  A**2  2.*A*X)/X**2 WRITE(6,100) P,A,X 100 FORMAT(' P=',F20.7,' A=',F14.7,' X=',F14.7) 1 CONTINUE 99 WRITE(6,*) '** Example 1 Ended **' STOP END P should be computed as 1.0 regardless of values of A and X. For A=10000., X=0.00001 for at least three PC Fortran 90 compilers, P is not computed as anywhere near 1.0! You can perturb A and X to see different results. Thus, subtracting nearly equal quantities, the most significant digits cancel leaving the least significant digits. In this case the result, which is usually an error converting X, is divided by a very small number (X**2), and so multiplied by a very large number. The result is disastrous numerical "answers". This has nothing to do with libraries, etc. Skip Knoble that is multiplied by a very large number)
 >I found numerical discrepancies >at the fourth and fifth significative digit. I ensured that the code for >both versions is the same. > >I still can't find the reason, and I start to beleive that there may be >differences in the intrinsic numerical functions used by Fortran of both >versions. Someone knows about differences in numerical calculations >between MS Fortran 5.1 and MS Powerstation that could explain these >differences ??? > >Someone already got the same problem ???  I don't know about those specific compilers, and I doubt that anyone would consider either as a reference standard. You might try running ELEFUNT (a TOMS testsuite), or CELEFUNT, whichever is appropriate, on these compilers. I assume you are running single precison. This discussion borders on flame bait, as some people consider the "correct" results to be the ones obtained by rounding off to single precision at every step (even inside the math functions). Other compilers, such as g77, don't normally invoke a single precision version of math functions, so the result is obtained by calculating in double precision (or better), followed by rounding to single precision. The latter approach looks much better when tested in ELEFUNT.  Lahey lf90 and lf95, for example, choose the approach of rounding off each operation to single precision, whereby the EXP() function, for example, is rated by ELEFUNT as having only 20 bit precision in the worst cases. If one goes to the opposite extreme, the design of the x86 and 68xx family is such that there is no significant penalty involved in carrying extra precision far enough to get a rating of 52 bit precision for the double precision intrinsic functions. Tim Prince
Herman D. Knoble, research associate
http://www.personal.psu.edu/hdk Penn State Center for Academic Computing 214 C Computer Building University Park, PA 168022101 phone: +1 (814) 8650818 fax: +1 (814) 8637049 Penn State Center for Academic Computing 214C Computer Building University Park, PA 168022101 phone: +1 (814) 8650818 fax: +1 (814) 8637049

Wed, 18 Jun 1902 08:00:00 GMT 


#5 / 8

Numerical discrepancies between MS Fortran 5.1 and Fortran Powerstation

Wed, 18 Jun 1902 08:00:00 GMT 


Yvan #6 / 8

Numerical discrepancies between MS Fortran 5.1 and Fortran Powerstation
Thanks all.
Quote: > I transfered to a DLL using MS PowerStation 4.0 some old numerical routines > that were part of a DOS program originally compiled with MS Fortran 5.1. If > left everything as is in the numerical part of the code. > To test the new library, I execute the same calculations with both the > original DOS program and the new DLL, and I found numerical discrepancies > at the fourth and fifth significative digit. I ensured that the code for > both versions is the same. > I still can't find the reason, and I start to beleive that there may be > differences in the intrinsic numerical functions used by Fortran of both > versions. Someone knows about differences in numerical calculations > between MS Fortran 5.1 and MS Powerstation that could explain these > differences ??? > Someone already got the same problem ??? > Thanks in advance for any help. > Yvan.

Wed, 18 Jun 1902 08:00:00 GMT 


#7 / 8

Numerical discrepancies between MS Fortran 5.1 and Fortran Powerstation

Wed, 18 Jun 1902 08:00:00 GMT 


Yvan #8 / 8

Numerical discrepancies between MS Fortran 5.1 and Fortran Powerstation
I found: MS Fortran 5.1 (DOS), simple precision: 1.1086 MS Fortran 5.1 (DOS), double precision: 0.94587 MS Fortran Powerstation 4.0, simple precision: 1.6735 MS Fortran Powerstation 4.0, double precision: 48.85 Actually these results helped me to reinforce my point, to my boss, that the reason of discrepancies is not a coding error in my DLL, but is due to the nature of the algorithms involved (optimization routines.. quite a lot of squared residuals weighted by variances) and the two compilers that behave differently in the presence of cummulative rounding errors. Thanks! Yvan.
Quote: > Of course the elementary functions should be checked. But it's also > true that numerical computation may be breaking down. It depends > a lot on the algorithm itself. When someone at Penn State tells > me that they switched operating systems or compilers and got different > "answers" and ask which set of "answers" are correct, I usually tell > them that neither should be trusted. Perturbing the input data (or constants) > in an application may prove useful. If small perturbations of input or > constants cause noticeable difference in results, then the numerical > algorithms being used are at fault. For example, run the program: > C==== Example 1: Dollars and Cents numeric breakdown. > C On IBM 3090 Mainframe, A=100., X=0.01. yields P=39. > C On PC's, A=10000., X=0.00001 yields P=68. > C Reverse the rolls of A and X (e.g., A=0.00001, X=10000.) > C and get correct result, P=1. using: > C DOUBLE PRECISION P,A,X > C doesn't change things much. > C > C NOTE: P is algebraically 1.0 for all A and X<>0. > C Penn State University Center for Academic Computing > C H. D. Knoble, August 1979. > REAL P,A, X > DO 1 I=1,99999 > WRITE(6,*) 'Please enter A & X (or press CtrlC to Quit):' > READ(5,*,END=99) A,X > P=((A+X)**2  A**2  2.*A*X)/X**2 > WRITE(6,100) P,A,X > 100 FORMAT(' P=',F20.7,' A=',F14.7,' X=',F14.7) > 1 CONTINUE > 99 WRITE(6,*) '** Example 1 Ended **' > STOP > END > P should be computed as 1.0 regardless of values of A and X. For > A=10000., X=0.00001 for at least three PC Fortran 90 compilers, > P is not computed as anywhere near 1.0! You can perturb A and X to see > different results. Thus, subtracting nearly equal quantities, > the most significant digits cancel leaving the least significant > digits. In this case the result, which is usually an error converting X, > is divided by a very small number (X**2), and so multiplied by a > very large number. The result is disastrous numerical "answers". > This has nothing to do with libraries, etc. > Skip Knoble > that is multiplied by a very large number)
>  > >I found numerical discrepancies > >at the fourth and fifth significative digit. I ensured that the code for > >both versions is the same. > > > >I still can't find the reason, and I start to beleive that there may be > >differences in the intrinsic numerical functions used by Fortran of both > >versions. Someone knows about differences in numerical calculations > >between MS Fortran 5.1 and MS Powerstation that could explain these > >differences ??? > > > >Someone already got the same problem ??? >  > I don't know about those specific compilers, and I doubt that anyone would > consider either as a reference standard. You might try running ELEFUNT (a > TOMS > testsuite), or CELEFUNT, whichever is appropriate, on these compilers. I > assume you are running single precison. This discussion borders on flame > bait, > as some people consider the "correct" results to be the ones obtained by > rounding off to single precision at every step (even inside the math > functions). Other compilers, such as g77, don't normally invoke a single > precision version of math functions, so the result is obtained by > calculating > in double precision (or better), followed by rounding to single precision. > The > latter approach looks much better when tested in ELEFUNT. >  > Lahey lf90 and lf95, for example, choose the approach of rounding off each > operation to single precision, whereby the EXP() function, for example, is > rated by ELEFUNT as having only 20 bit precision in the worst cases. If > one > goes to the opposite extreme, the design of the x86 and 68xx family is such > that there is no significant penalty involved in carrying extra precision > far > enough to get a rating of 52 bit precision for the double precision > intrinsic > functions. > Tim Prince
> Herman D. Knoble, research associate
> http://www.personal.psu.edu/hdk > Penn State Center for Academic Computing > 214 C Computer Building > University Park, PA 168022101 > phone: +1 (814) 8650818 > fax: +1 (814) 8637049 > Penn State Center for Academic Computing > 214C Computer Building > University Park, PA 168022101 > phone: +1 (814) 8650818 > fax: +1 (814) 8637049

Wed, 18 Jun 1902 08:00:00 GMT 


