Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU
Path: utzoo!decvax!bellcore!ulysses!ucbvax!UTAH-CS.ARPA!cetron%utah-cbd
From: cetron%utah-cbd@UTAH-CS.ARPA (Ed Cetron)
Newsgroups: mod.computers.vax
Subject: Re:  Number crunching
Message-ID: <8607141545.AA00567@utah-cbd.ARPA>
Date: Mon, 14-Jul-86 11:45:42 EDT
Article-I.D.: utah-cbd.8607141545.AA00567
Posted: Mon Jul 14 11:45:42 1986
Date-Received: Tue, 15-Jul-86 19:32:08 EDT
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The ARPA Internet
Lines: 21
Approved: info-vax@sri-kl.arpa


	I have found (totally empirically) that trying to code
large algorithms is C is somewhat confusing since in order to
optimize the calculations one must code it that way.  I have
yet to see a C compiler that optimizes the numerical calculations
(i.e. keeping things in registers to use in chained calculations).

	Additionally, C in the 'proper' standard is supposed to do
everything in double precison and simply convert on input/output
(yes i know not all compilers do this....) and for certain operations
(such as integer calculations) this is highly ineffecient.

	C is not so much worse that FORTRAN for simply coding a problem
where speed is not critical,  but for large algorithms where speed is
very important, the FORTRAN compilers tend to give smaller and faster
code than do the C compilers....

	NOTE WELL: this is a broad generalization and there will always
be several specific cases which will prove something (or anything) else...

-ed cetron