🚀 go-pugleaf

In article <1990Dec5.185852.5191@alchemy.chem.utoronto.ca> mroussel@alchemy.chem.utoronto.ca (Marc Roussel) writes:
>     It's not just infix.  Correct me if I'm wrong, but don't you have to
>declare every last variable in C?  Given some relatively simple conventions
>and judicious use of implicit, you almost never have to declare a simple
>variable in Fortran.  You also don't have to worry about which sqrt or log to
>use since the ANSI 77 standard.  (Don't you have to do this in C?  My
>impression was that C compilers, like F66 compilers, had to be told to
>use single precision functions here and double precision functions there.)

Yes, this is true, but I don't think of the need for declarations
as an aspect of the syntax. Overloading of functions (e.g. sqrt)
is indeed convenient. I'm not so sure about implicit declaration
of variables.  It saves typing, to be sure, but I suspect it is
also a nasty source of bugs. Moreover, undeclared variables
virtually never get commented, and most variables deserve a
comment.

>>About the only things I can
>>thnk of are that the power function is not an operator in C and that
>>C does not have a complex type.
> 
>     Believe it or not, those are a concern to your typical scientific
>programmer.  It's easy to write an inefficient power function; it's
>easier to let the compiler writer worry about that once.  Since
>exponentiation is such a common operation, why should every programmer
>write his own?  The same thing goes (doubly so!) for the complex type.  If the
>language doesn't support it directly you wind up with a large number of
>mutually incompatible libraries for a set of operations used over and
>over again by everyone.

I sort of agree about the complex type, though I think that this
could be fairly easily solved by the inclusion of a standard
complex class in a library (probably C++ rather than C). As for
exponentiation, I think you are confusing two issues. I agree
that it is pointless for everybody to write his or her own power
function. That just means that it is something for which standard
library functions ought to be available, as indeed they are. This
is distinct from the issue of whether it is treated as an
operator. The terminology here isn't 100% standard, so maybe we
don't have the same notion of "operator".  What I mean by
"operator" is "function whose properties are known to the
compiler". I think that this is a reasonable characterization of
the typical usage. In some languages there is no ordering
difference between operators and functions. Thus, by my definition
LISP special functions are operators because the
compiler/interpreter has to know not to evaluate their arguments.
But they have the same ordering (prefix) as ordinary functions. In
languages like C and Fortran the operators are infixed whereas
ordinary function calls are prefixed and they are overloaded (e.g
+ adds both reals and ints). So, the differences between C and
Fortran wrt to the power function do not, in principle, have to
do with whether the individual programmer writes it or not, but
rather with (a) whether it is overloaded (and this is not an
issue in C++) and (b) whether it is prefixed or infixed.
Personally, I don't care much about the latter, though I know
some people do. I figure that if you do computations of much
complexity you will need lots of functions in either language
(and hence they will be prefixed), and that prefix or suffix
notation makes complex expressions easier to read if they are
well laid out.  But I recognize that infixation of the power
function is typical mathematical usage and hence that a language
that does it this way is more comfortable for some people.

>>I've never found it at all difficult to
>>translate equations into C. The main difficulty is avoiding duplicate
>>computation, and that has to be done explicitly in Fortran too.
>
>     It's not that it's difficult to simply "translate" an equation
>into C, it's that the code that has to be written around it is more
>elaborate.  When I pass an array into a subroutine in Fortran, I can
>treat it exactly as I would in the calling routine.  In C, I have to
>remember that I'm only getting a pointer and do appropriate arithmetic
>to extract the array elements.  (Again, I'm more than willing to be
>corrected on this point.)

No, you can use array subscripting notation for an array argument in C.
Suppose you have the following simple function, which is declared as
receiving a pointer to a float. You can pass it either an array of
floats or a pointer to float since the former is converted to the latter
by the rules you mention. Nonetheless, the array subscripting syntax
is permitted. This is because it is equivalent BY DEFINITION to pointer
arithmetic. That is, a[i] and *(a + i) are equivalent by definition;
some compilers actually do this transformation explicitly

float
FindMax(array,length)
float *array;
int length;
{
	int i;
	float max;

	max = array[0];
	for(i = 1; i < length; i++){
		if(array[i] > max) max = array[i];
	}
	return(max);
}


>Look, I'm sure you don't mind this sort of
>thing, but I do.  I guess I just don't see why I should learn a new language
>when, by and large, I write ODE and algebraic equation solvers to which
>task Fortran's facilities (unlike C's) are ideally suited.  C isn't a
>vegematic and I just get annoyed when someone tries to sell it to me as
>that.  If you already know C, it probably isn't a big deal to use it for
>scientific computing.  If you don't, why bother learning it until you
>run into a problem that doesn't fit Fortran's capabilities?

I never meant to argue that you should. My query has to do with why
Fortran folks find C syntax so unpleasant and difficult. If Fortran
is going a good job for you, that's fine.

For the sort of things that you mention, I'm willing to believe that
Fortran is fine. I do think, however, that there is a lot of programming
done in Fortran that would be better done in other languages, or by
programmers acquainted with concepts that are more likely to be acquired
through the study of other languages. For a fair amount of mathematical
programming (I eschew the term "scientific programming" because it ought
properly to cover much more than the narrow class of things it is applied
to), the programming problems are fairly simple (from the point of
view of sophistication of data structures and control structure) and
the hard work is the numerical analysis. Fortran is probably fine for
this kind of thing. But when instead of solving ODEs you are writing
a time series editor or a visualization program or something like that,
Fortran arguably becomes a straightjacket and a "systems programming"
language like C can be a big help.


						Bill