Xref: utzoo comp.lang.fortran:4142 comp.lang.c:34236 Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!zaphod.mps.ohio-state.edu!uakari.primate.wisc.edu!uflorida!haven!uvaarpa!murdoch!murdoch.acc.virginia.edu!bglenden From: bglenden@mandrill.cv.nrao.edu (Brian Glendenning) Newsgroups: comp.lang.fortran,comp.lang.c Subject: Re: Fortran vs. C for numerical work (SUMMARY) Message-ID: Date: 26 Nov 90 21:23:35 GMT References: <21884@orstcs.CS.ORST.EDU> <1990Nov21.220816.15220@rice.edu> <2173@tuvie> Sender: news@murdoch.acc.Virginia.EDU Organization: National Radio Astronomy Observatory Lines: 104 In-Reply-To: hp@vmars.tuwien.ac.at's message of 26 Nov 90 16:33:05 GMT A few days ago I posted a note asking: >It is often stated that Fortran is better than C for numerical work. I >am interested in compiling both the standard list of such arguments >and what any counterarguments might be. Here is my summary of the responses I received. If anyone wants to read the raw responses please email me and I will be happy to forward them (160k+!). Many thanks to all the respondents who so generously answered my query. 1. Pointer aliasing. SUBROUTINE FOO(A,B) void foo(a,b) REAL A(*), B(*) float *a, *b; The fortran standard requires that A,B be unaliased. In C a,b may well be aliased, and there is no portable way to say that they are unaliased. Compilers on serious vector machines (at least) will have ways of declaring unaliased pointers. The programmer can make a mistake doing this, but of course the programmer can also really pass aliased arrays in Fortran as well. Although I understand that "noalias" is hated by C purists, I wish that it had made it into the ANSI standard. (Maybe I just don't understand the arguments against it). 2. C has no conformant arrays, i.e. you can't do the equivalent of: SUBROUTINE FOO(A, M, N) REAL A(M,N) In C you either have to do your own indexing *(a + j*m +i) or have pointers to pointers *(*(a + i) + j). You can in either case use a macro expansion ARRAY(a,i,j) to take some of the sting out of the syntax. 3. In fortran functions like sin, cos, ** are intrinsic. I think that ANSI C has a method by which compilers may make sin, cos etc intrinsic, but I don't remember how it works. Maybe a wizardly followup could answer this question. A ** builtin _is_ handy. 4. Fortran has complex variables. If you need to do a lot of complex arithmetic this might be a show stopper unless you have a good source of C complex arithmetic routines. Even then it is not going to be as convenient as in Fortran. 5. There are many numerical libraries written for Fortran. This is likely not a fundamental problem on any modern system scientific programmers would use, e.g. either use f2c to convert it or link in the fortran, but it does impose either some programmer time overhead in the translation or make the linking process (at least) a bit non-portable. 6. C can ignore the placement of parentheses 7. "C has too many system dependent aspects (e.g. round up or down when dividing negative integers)." Both of these need to be understood by a scientific programmer so they can work around them. 8. C does everything in double. Not (necessarily) with ANSI C. ====== I will not go into the reasons why C was claimed to be better for numerical work Fortran (basically better data typing, control structures, dynamic memory etc). _MY_ sumarry-summary is as follows: I conclude that for scientific programming there are no overwhelming reasons not to use C unless you do a lot of complex arithmetic. Personally I don't consider the "pointer aliasing defeats optimizers" to be too serious. Anyone who cares about speed is going to profile their code, and at that time it shouldn't be too difficult to tell the compiler what is not aliased in the "hot spot" routines. Whether or not the switch to C is worthwhile will depend on whether the above quirks in C outweigh the benefits of having "more modern" data typing and control structures. Fortran is probably more portable (*) and will run faster without tweaking. On the other hand Fortran may be harder to maintain, and it is a poor fit to algorithms that are best expressed with types more involved than n-dimensional arrays. (*) I realize that it is not that hard to write portable C. I think it's fair to say that it's easier to write portable Fortran for numeric work, though. When and if we have fortran9? available the story may be different (but it's getting pretty late in the day for F9x to come riding over the horizon to save us). Brian -- Brian Glendenning - National Radio Astronomy Observatory bglenden@nrao.edu bglenden@nrao.bitnet (804) 296-0286