Re: about c to fortran

Hello,

wakun@xxxxxxxxx wrote:

<snip>

 /* written in C */
 double PI, DUMMY;
 PI = 4.0*atan(1.0);
 DUMMY = 8.0*sin(PI*0.2) + 0.85312;
 printf("%30.20lf %30.20lf\n", DUMMY, PI);


OK, but why Fortran 77?
It's been obsolete for 15 years.  :-)

If you're used to using C, free format will be easier
for you than fixed format.

Even if you must use a sadly obsolete compiler,
there are GPL'ed format conversion utilities on the net.
So you can edit free format, and compile fixed format.

C     WRITTEN IN FORTRAN
       IMPLICIT DOUBLEPRECISION(A-H,O-Z)
       REAL*8 DUMMY, PI

PI = 4.D0*DATAN(1.D0) 

Why datan()?  It's usually considered better
practice to use the generic atan().
Some may disagree, preferring the added type checking
to be worth the pain of moving to a processor
with different data sizes.  YMMV
I almost always use the generics.

DUMMY = 8.0*DSIN(PI*0.2) + 0.85312 

Likewise, use generic sin() rather specific dsin().

123  FORMAT(F30.20, F30.20)
       WRITE (*,123) DUMMY, PI


Some prefer write( *, '(2f30.20)') dummy, pi
but it's your call how you spell things.

The output is
C:              5.55540201833978480000   3.14159265358979310000
FORTRAN: 5.55540210790892086123   3.14159265358979311600

There are hair difference between them. However, all the variables are
double precision, I am wondering how is the difference comming? A guy
told me that it is due to the  significant figure , but why the two
PI's are close to each other while DUMMY's  are not? How can I get the
same output?


Well, let's see ...  Try changing the "0.2" in the argument to sin()
to be "0.2d0", and change "0.85312" to "0.85312d0"
0.2 is not an exact binary number, and I rather doubt 0.85312 is,
either (but I haven't checked).

See if that resolves at least some of your difference.
If it does, I or someone else, can try to explain why.

Are these compilers from the same vendor?  Same code generator?
Are they using the same fp modes (rounding, especially)?

BTW, I have also written a piece of code to implement a iterative
procedure in C and FORTRAN. This time, because of the initial hair
difference of inputs, the difference of outputs are significant


Yep!  These things can accumulate during iterations.

HTH

--
Cheers!

Dan Nagle
Purple Sage Computing Solutions, Inc.
.

Relevant Pages

  • Re: Automatic detection of a COBOL dialect ?
    ... >I must say i have little knowledge about COBOL. ... >For now, I automatically detect fixed or free format, like this: ... > - else it is free format. ... it is fixed format and does not have any number on the 1-6 cols. ...
    (comp.lang.cobol)
  • getting specific line numbers from a file (faster way)
    ... The dimensions and number of dummy lines are known. ... Note that I can't use something like: grep -E '^Imax Jmax' filename ...
    (comp.unix.shell)
  • Automatic detection of a COBOL dialect ?
    ... I must say i have little knowledge about COBOL. ... For now, I automatically detect fixed or free format, like this: ... Does anyone know a trick to distinguish a fixed format cobol program ...
    (comp.lang.cobol)
  • Re: bullets in smartart
    ... Insert a text box with dummy text outside the SmartArt. ... Use the yellow format painter brush to copy this format to the text ... Microsoft PowerPoint MVP Team und PowerPoint-User-Team ...
    (microsoft.public.powerpoint)
  • Calculating Sum along the row and column
    ... I have a table with following format and values (a dummy one): ... I would like to come out with a report like format: ... plus grant total at the end for each column based on Catg? ...
    (comp.databases.oracle.misc)