Xref: utzoo comp.lang.c:10989 comp.lang.fortran:835 Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!mailrus!ames!hc!lanl!beta!jlg From: jlg@beta.lanl.gov (Jim Giles) Newsgroups: comp.lang.c,comp.lang.fortran Subject: Re: C vs. FORTRAN Keywords: C FORTRAN vectorizing supercomputers religion Message-ID: <20480@beta.lanl.gov> Date: 29 Jun 88 16:21:34 GMT References: <3136@phoenix.Princeton.EDU> <19633@watmath.waterloo.edu> <143@quintus.UUCP> Organization: Los Alamos National Laboratory Lines: 36 In article <143@quintus.UUCP>, ok@quintus.uucp (Richard A. O'Keefe) writes: > [...] > Not to knock either C or Fortran, but this may be a case where C is better > to use than Fortran. Just because ** _looks_ like a simple operation (not > that different from *) doesn't mean that it isn't a call to a costly function. > I have seen published Fortran code where polynomials were evaluated with an > O(N * log(N)) algorithm (N being the degree of the polynomial) instead of an > O(N) algorithm, presumably because the programmer thought ** must be cheap. > [...] The exponentiation operator isn't bad just because some people use it badly. Your example could have been coded just as badly with C (by using the same algorithm and substituting function calls for the exponentiation operator - it wouldn't be an intrinsic function if it wasn't cheap, would it?). If simple looking expressions should really be restricted to doing only simple things, the C should not have macros (which can hide a lot of complexity). Also, Fortran doesn't _require_ a programmer to use **. You could code without it. But, the exponentiation operator is an example of a feature which allows the compiler to make optimizations without the user having to sacrifice readability. X**3 is more readable than X*X*X (particularly is X is an expression). X**3.5 is more readable than EXP(3.5*LOG(X)). The compiler automatically selects which implementation to do, in general helping speed the code. If you always do pow(X,Y), the compiler has no choices to make. The purpose of all higher level features of a language is to make it easier for a _good_ programmer to do his job. A feature which does this should be considered for inclusion no matter how badly it _might_ be misused. If the potential for misuse doesn't even result in incorrect code (as in this case), then there is no reason not to include the feature. J. Giles Los Alamos