🚀 go-pugleaf

In article <15078@bfmny0.UU.NET>, tneff@bfmny0 (Tom Neff) writes that
rewriting extant FORTRAN applications wholesale with C isn't necessarily
a good idea. I agree entirely. FORTRAN was designed to support numerical
programming well; it does this. It has a wealth of mathematical types
and functions defined into the language. In particular, basically much
of libm is known to the compiler, so a *good* implementation of FORTRAN
can code it all inline, and perform compile-time optimizations that
depend on knowing details about how functions are being called.

In C you can extend the language using structures (for the COMPLEX type,
for example) and subroutines to implement all the mathematical
operations. This doesn't read much worse than having the language
features directly available, though functional notation isn't as nice as
infix for the basic arithmetic operators as applied to complex (for
example). Unfortunately, for many applications it will be *drastically*
slower. 

You can always tune the code by expanding out all the arithmetic in-line
and hand-tweaking it. Thanks anyway, I'd rather maintain the FORTRAN.
Much.

C++ offers the possibility of extending the language at compile time to
support numerical applications, retaining both a clean notation for
representing equations and the performance of allowing the compiler to
know the internals of the algorithm. A few months ago I posted an
example power() routine that allowed me to code

	printf("%g", power(sin(atof(argv[1])), 2));

and upon examining the assembler produced by G++ I got

	call atof;
	call sin;
	multiply the return value by itself;
	call printf;

This is the kind of performance people expect good FORTRAN compilers to
produce. C can't do that without getting uglier to write and maintain
than the FORTRAN. C++ can.

As always, these are just my opinions. My experience with numerical
programming is reasonably limited; if I'm wrong please be kind enough to
explain why politely. Thank you.

-Bennett
bet@orion.mc.duke.edu