C vs. FORTRAN

[Jim Giles]

In article <143 at quintus.UUCP>, ok at 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