Path: utzoo!censor!geac!torsqnt!news-server.csri.toronto.edu!rutgers!cs.utexas.edu!uunet!mcsun!ukc!slxsys!ibmpcug!mantis!mathew
From: mathew@mantis.UUCP (mathew)
Newsgroups: comp.lang.misc
Subject: Re: Fortran vs. C for numerical work
Message-ID: <X2uRT4w163w@mantis.UUCP>
Date: 6 Dec 90 19:09:08 GMT
References: <1990Dec5.185852.5191@alchemy.chem.utoronto.ca>
Organization: Mantis Consultants, Cambridge. UK.
Lines: 96

mroussel@alchemy.chem.utoronto.ca (Marc Roussel) writes:
> >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?

He didn't say it didn't exist, he said it wasn't an operator. You have to
do a = pow(b,c) instead of a = b**c or a = b^c or whatever.

>                The same thing goes (doubly so!) for the complex type.  If th
> 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.

So use C++! Example:

#include <complex.h>

main()
{
   complex xx;
   complex yy = complex (1, 2.718);
   xx = log(yy / 3);
   cout << 1 + xx;
}

With C++, you can even define an infix notation for pow, and write things
like  a = b toThe c;

>      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.)

main()
{
int a[10];

   a[1] = 4;
   foo(a);
}

foo(int a[10])
{
int c;

   c = a[1];
   printf("%d\n", c);
}

Was that really too painful? Perhaps you'd like to show us how much easier
it is in FORTRAN?

>                   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.

You think FORTRAN is ideally suited to writing *algebraic* equation solvers?!

Reminds me of a great book I saw: "Artificial Intelligence Programming in
FORTRAN". It's a laugh a minute! You should see the crude hacks they had to
do to avoid using recursion...

[ Yeah, I know, some FORTRAN compilers have recursion. But until they all do,
  using it isn't exactly going to do wonders for your code's portability. ]

>        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?

If you already know FORTRAN, it probably isn't a big deal to use it for
scientific computing. If you don't, why bother learning it at all? I remain
to be convinced that there's anything you can do in FORTRAN that you can't
do with more grace in a different language.

Now, if you're talking about raw speed, then you've got a point. FORTRAN is
faster than most other languages *at* *the* *moment*. But that's because
companies like IBM have pumped millions of dollars into making machines which
can run FORTRAN as quickly as possible.

Personally, I'd like to see 'em pump money into LISP machines. Common Lisp's
great for numerical stuff... if only it were faster!


mathew.
--
Mantis Consultants, Unit 56, St. John's Innovation Centre, Cambridge. CB4 4WS.
   "CP/M is to metric as cockroaches are to a Timex watch" - booter@catnip