john@ghostwheel.unm.edu (John Prentice) (11/26/90)
There has been much discussion about using f2c to convert
Fortran to C. Out of curiosity, I ran my previously
posted complex root solver for quadratic equations through
f2c. The Fortran code was:
program root
c
c solve a*z**2 + b*z + c = 0 for complex a,b,c,z
c
implicit none
real zero,one,two,three,four,five
parameter (zero=0.0,one=1.0,two=2.0,three=3.0,four=4.0,
* five=5.0)
complex a,b,c,root1,root2,disc,sqrt1
c
c hard-wire in a,b,c to make it simple
c
a=(one,zero)
b=(-three,two)
c=(five,-one)
c
c calculate the discriminant
c
disc=b**2-cmplx(four)*a*c
c
c calculate the upper half plane square root of the
c discriminant
c
sqrt1=sqrt(disc)
c
c now calculate the roots
c
root1=(-b+sqrt1)/(cmplx(two)*a)
root2=(-b-sqrt1)/(cmplx(two)*a)
c
c print out result
c
write (*,'('' the roots are: '',1p2e15.5/16x,1p2e15.5)') root1,
* root2
c
end
and the resulting C code (via f2c) was:
/* -- translated by f2c (version of 2 November 1990 13:43:50).
You must link the resulting object file with the libraries:
-lF77 -lI77 -lm -lc (in that order)
*/
#include "f2c.h"
/* Table of constant values */
static integer c__2 = 2;
/* Main program */ MAIN__()
{
/* System generated locals */
complex q__1, q__2, q__3, q__4;
/* Builtin functions */
void pow_ci(), c_sqrt(), c_div();
integer s_wsfe(), do_fio(), e_wsfe();
/* Local variables */
static complex disc, a, b, c, root1, root2, sqrt1;
/* Fortran I/O blocks */
static cilist io___8 = { 0, 6, 0, "(' the roots are: ',1p2e15.5/16x,1p2e\
15.5)", 0 };
/* solve a*z**2 + b*z + c = 0 for complex a,b,c,z */
/* hard-wire in a,b,c to make it simple */
a.r = (float)1., a.i = (float)0.;
b.r = (float)-3., b.i = (float)2.;
c.r = (float)5., c.i = (float)-1.;
/* calculate the discriminant */
pow_ci(&q__2, &b, &c__2);
q__4.r = a.r * (float)4. - a.i * (float)0., q__4.i = a.i * (float)4. +
a.r * (float)0.;
q__3.r = q__4.r * c.r - q__4.i * c.i, q__3.i = q__4.r * c.i + q__4.i *
c.r;
q__1.r = q__2.r - q__3.r, q__1.i = q__2.i - q__3.i;
disc.r = q__1.r, disc.i = q__1.i;
/* calculate the upper half plane square root of the */
/* discriminant */
c_sqrt(&q__1, &disc);
sqrt1.r = q__1.r, sqrt1.i = q__1.i;
/* now calculate the roots */
q__3.r = -(doublereal)b.r, q__3.i = -(doublereal)b.i;
q__2.r = q__3.r + sqrt1.r, q__2.i = q__3.i + sqrt1.i;
q__4.r = a.r * (float)2. - a.i * (float)0., q__4.i = a.i * (float)2. +
a.r * (float)0.;
c_div(&q__1, &q__2, &q__4);
root1.r = q__1.r, root1.i = q__1.i;
q__3.r = -(doublereal)b.r, q__3.i = -(doublereal)b.i;
q__2.r = q__3.r - sqrt1.r, q__2.i = q__3.i - sqrt1.i;
q__4.r = a.r * (float)2. - a.i * (float)0., q__4.i = a.i * (float)2. +
a.r * (float)0.;
c_div(&q__1, &q__2, &q__4);
root2.r = q__1.r, root2.i = q__1.i;
/* print out result */
s_wsfe(&io___8);
do_fio(&c__2, (char *)&root1, (ftnlen)sizeof(real));
do_fio(&c__2, (char *)&root2, (ftnlen)sizeof(real));
e_wsfe();
} /* MAIN__ */
/* Main program alias */ int root_ () { MAIN__ (); }
#ifdef uNdEfInEd
comments from the converter: (stderr from f2c)
MAIN root:
#endif
Notwithstanding that the C code is not what I would regard as
a model of clarity, it also will not execute on the Sun 3 I
tried it on. It will compile and link, but it dies on a
segmentation fault. I would be curious if other people would
try it and see if it works on their machines.
If this is typical of the reliability of f2c (assuming I didn't
just make a dumb mistake somewhere), then I would say it is
a ways from being a production tool for porting Fortran to C.
That weakens the argument for using the huge Fortran math
libraries with C numerical routines.
I have had some success in the past using f2c to convert Fortran
to C, though on one test it expanded a 50 line Fortran program
to nearly 1000 lines (the code was a simple Fortran parser).
I can accept that however given that the conversion of i/o routines
is not that easy and C lacks most of the string handling
ability of Fortran. What are other peoples experience with
f2c?
By the way, this note is not meant as a criticism of the people
working on f2c. I think this is an excellant project and the
need for a good Fortran to C converter is great. It is meant
more to find out if we are anywhere near that goal and to suggest
that it may be a bit premature to suggest abondoning Fortran for
numerical work if you need the existing math libraries.
John Prentice
Amparo Corporation
Albuquerque, NM
john@unmfys.unm.eduajayshah@almaak.usc.edu (Ajay Shah) (11/26/90)
In article <1990Nov25.204354.12324@ariel.unm.edu> john@ghostwheel.unm.edu (John Prentice) writes: (a situation where f2c-generated code doesn't work on a Sun3) >If this is typical of the reliability of f2c (assuming I didn't >just make a dumb mistake somewhere), then I would say it is >a ways from being a production tool for porting Fortran to C. I think this is not typical. Make-ing f2c is slightly nontrivial; I had a few false tries on a Sparcstation before getting it right. I wish hints on getting the f2c system to work on a given machine are better documented. Maybe comp.lang.fortran can put together user notes on f2c in this spirit? Another point you should probably note is that f2c is a *very* dynamic program, there are changes and bugfixes to the source every week or so. Your problem may well be a bug which has been fixed in case you're using an old f2c system. >I have had some success in the past using f2c to convert Fortran >to C, though on one test it expanded a 50 line Fortran program >to nearly 1000 lines (the code was a simple Fortran parser). >I can accept that however given that the conversion of i/o routines >is not that easy and C lacks most of the string handling >ability of Fortran. What are other peoples experience with >f2c? I'm not used to thinking of fortran as being a place to do string handling! :-) Translation of tacky fortran-I/O is definitely a challenge, and I'm not surprised that f2c comes up with strange-looking code in such situations. Maybe I'm lucky. I write fortran which is just a set of clean control structures (never used an arithmetic if or a computed goto in my life) with minimal use of strange fortran I/O and weird common/equivalence tricks. My code looks a lot like pascal given the liberal use of Sun fortran extensions (like label-free do loops and "implicit undefined (a-z)") and liberal use of /usr/lib/cpp. At the end of the day, I could easily translate my code to Pascal or C by hand, and find f2c to be a useful crutch in such translation. As for the tragic piles of dusty-decks lying around, f2c generates correct code as far as I can tell and I never look at the generated C. It was rotten code to start with, and the generated C is no better. Anytime I need to make changes on code in fortran-66 or so, I just throw it away and rewrite from scratch. It's hard, but life is tough! >By the way, this note is not meant as a criticism of the people >working on f2c. I think this is an excellant project and the >need for a good Fortran to C converter is great. It is meant >more to find out if we are anywhere near that goal and to suggest >that it may be a bit premature to suggest abondoning Fortran for >numerical work if you need the existing math libraries. In the spirit of the above, I think f2c *has* solved my problem of leaving fortran! If there are bugs, and I don't doubt there are many, they need to be ironed out. The fundamental philosophy of f2c is perfectly on track, IMHO. We urgently need to get scientific computing out of fortran and into Pascal/C. Users of f2c all around are chipping away at this larger goal everyday. -- _______________________________________________________________________________ Ajay Shah, (213)734-3930, ajayshah@usc.edu The more things change, the more they stay insane. _______________________________________________________________________________
seibel@cgl.ucsf.edu (George Seibel) (11/26/90)
In article <28393@usc> ajayshah@almaak.usc.edu (Ajay Shah) writes: > >I'm not used to thinking of fortran as being a place to do >string handling! :-) I think the most persistent myth in all of computing is the superiority of C over fortran for string handling. C is vastly superior for *byte* handling, but *bytes are not strings*. Fortran has string data types and string operators. C doesn't. It was probably a bad choice on the part of the designers of fortran 77 to use the term "CHARACTER" for what should perhaps have been called the "STRING" data type. Nevertheless, fortran CHARACTER variables are in fact strings, and the language contains powerful facilities for their manipulation. I've written elaborate parsers in both languages; in both cases I had to augment the existing string handling functionality with a couple of 5-line functions, i.e., neither language was "perfect", but neither language was "incapable". One thing that the C string approach works better for is dealing with arrays of strings with widely varying lengths. Here C allows you to save memory by using pointers to contiguous byte arrays, whereas the easy way to do it in fortran is with fixed-width strings. There are efficient fortran solutions as well, using indices into character arrays or substrings. All in all, when I think about the areas in which C is better than fortran, string handling is not one of them. George Seibel, UCSF seibel@cgl.ucsf.edu
ok@goanna.cs.rmit.oz.au (Richard A. O'Keefe) (11/27/90)
In article <16414@cgl.ucsf.EDU>, seibel@cgl.ucsf.edu (George Seibel) writes: > In article <28393@usc> ajayshah@almaak.usc.edu (Ajay Shah) writes: > >I'm not used to thinking of fortran as being a place to do > >string handling! :-) > I think the most persistent myth in all of computing is the superiority > of C over fortran for string handling. I'll challenge that. I reckon the most persistent myth is that string handling is a good thing. Structured information should be stored as trees &c, not as strings. I can, however, testify that it took me five days to do in C (two weeks after I started using C) to do what it had taken a friend five months to do with PL/I (Fortran character variables are a restriction of PL/I). How come? Because C *hasn't* got strings, but *has* got the tools you need to build what you want. Strings are the (tar) pits. -- I am not now and never have been a member of Mensa. -- Ariadne.
gt4512c@prism.gatech.EDU (BRADBERRY,JOHN L) (11/27/90)
In article 4305 (Richard A. O'Keefe <ok@goanna.cs.rmit.oz.au>) writes: >> I think the most persistent myth in all of computing is the superiority >> of C over fortran for string handling. > >I'll challenge that. I reckon the most persistent myth is that string >handling is a good thing. Structured information should be stored as >trees &c, not as strings. Once again, I find it rather amusing that some of us insist on 're-defining the job' instead of taking an honest look at the tools available! In many cases, structured representation of data is indeed a great way to solve problems. However, I wouldn't declare it an 'all encompassing' solution just as a carpenter wouldn't build a house with just a hammer and saw! > >I can, however, testify that it took me five days to do in C (two weeks >after I started using C) to do what it had taken a friend five months >to do with PL/I (Fortran character variables are a restriction of PL/I). >How come? Because C *hasn't* got strings, but *has* got the tools you >need to build what you want. Strings are the (tar) pits. > 5 days versus 150 days for solving the same problem! Hmmmm... Perhaps your friend should find another line of work or MENSA SHOULD recruit YOU! -- John L. Bradberry |Georgia Tech Research Inst|uucp:..!prism!gt4512c Scientific Concepts Inc. |Microwaves and Antenna Lab|Int : gt4512c@prism 2359 Windy Hill Rd. 201-J|404 528-5325 (GTRI) |GTRI:jbrad@msd.gatech. Marietta, Ga. 30067 |404 438-4181 (SCI) |'...is this thing on..?'