Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utcs!mnetor!seismo!lll-crg!mordor!sri-spam!nike!ucbcad!ucbvax!YALE.ARPA!GROPP-BILL
From: GROPP-BILL@YALE.ARPA.UUCP
Newsgroups: mod.computers.vax
Subject: Re: Number crunching
Message-ID: <8607142350.AA07058@ucbvax>
Date: Mon, 14-Jul-86 20:28:57 EDT
Article-I.D.: ucbvax.8607142350.AA07058
Posted: Mon Jul 14 20:28:57 1986
Date-Received: Tue, 15-Jul-86 04:47:29 EDT
Sender: daemon@ucbvax.BERKELEY.EDU
Reply-To: <GROPP-BILL@YALE.ARPA>
Organization: The ARPA Internet
Lines: 41
Approved: info-vax@sri-kl.arpa


        From: cetron%utah-cbd@utah-cs.arpa (Ed Cetron)
    
        On the other hand, C does this kind of stuff extremely well -
        but it is terrible for large brute force number crunching - and
        it is ludicrous to use it in that fashion....
    
      I have heard this several times, and I still don't understand it.  I
    can see why C is better for systems programming than Fortran or Pascal,
    but why is C supposedly worse at number crunching than Fortran?  What can
    be done easily in Fortran that is difficult or impossible in C?

There are two main reasons, one real, the other historical.  The first
reason is that c does all floating point operations in double (KR p 184,
section 6.2).  This can be a serious problem in applications that
require only float precision.  The historical reason comes from the fact
that most professionally done Fortran compilers for the faster, number
crunching machines generate significantly better object code than c
compilers on the same machine.  This can be traced to the early
development of c (the "register" declaration is of no use/need to
sufficiently sophisticated code generator; note section 8.1 in KR) and
the continuing belief by many that c generates excellent code.  This
belief, where true at all, generally does not apply to floating point
operations and the kinds of expressions that contain them.

Also, it is impossible to pass a 2 or higher dimensioned array AS SUCH
where the dimensions are not known at compile time (section 8.3 and 15,
KR).  Instead, you must pass a pointer and do the pointer arithmetic
yourself.  This can be extremely inconvenient in many number-crunching
applications.  For an example, consider a subroutine library to handle
matrices of arbitrary size such as the Fortran LINPACK and EISPACK.

Finally, there is the portability question.  Many number-crunching
programs are intended for wide distribution on the large mainframes,
many of which did not (some still do not) have a c compiler.

Having said all of that, there are clearly cases, particularly in
fancier numerical codes using adaptivity and needed dynamic memory
allocation and structures, where c is often the best choice.
                                                Bill
-------