Numerical discrepancies between MS Fortran 5.1 and Fortran Powerstation 
Author Message
 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  
 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  
 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  
 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 Ctrl-C 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  16802-2101
phone: +1 (814) 865-0818
fax: +1 (814) 863-7049
Penn State Center for Academic Computing
214-C Computer Building
University Park, PA 16802-2101
phone: +1 (814) 865-0818
fax: +1 (814) 863-7049



Wed, 18 Jun 1902 08:00:00 GMT  
 Numerical discrepancies between MS Fortran 5.1 and Fortran Powerstation


Wed, 18 Jun 1902 08:00:00 GMT  
 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  
 Numerical discrepancies between MS Fortran 5.1 and Fortran Powerstation


Wed, 18 Jun 1902 08:00:00 GMT  
 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 Ctrl-C 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  16802-2101
> phone: +1 (814) 865-0818
> fax: +1 (814) 863-7049
> Penn State Center for Academic Computing
> 214-C Computer Building
> University Park, PA 16802-2101
> phone: +1 (814) 865-0818
> fax: +1 (814) 863-7049



Wed, 18 Jun 1902 08:00:00 GMT  
 
 [ 8 post ] 

 Relevant Pages 

1. Ms Fortran 5.1 or MS Fortran Powerstation

2. Ms Fortran 5.1 or MS Fortran Powerstation

3. Microsoft FORTRAN Powerstation 1.0 vs. FORTRAN 5.1

4. Recognizing FORTRAN files in MS FORTRAN 5.1

5. How to make MS DOS beep using MS Fortran 5.1

6. Linking MS Fortran 5.1 with MS C/C++ 7.0

7. Converting Fortran 5.1 to Powerstation 4.0

8. Compiling legacy fortran code under MS Fortran Powerstation - output format question

9. How to install Ms Fortran 5.1

10. I need help with MS FORTRAN Compiler 5.1

11. General Protection fault on read instruction, in a DLL written in MS Fortran 5.1

 

 
Powered by phpBB® Forum Software