Fortran vs. C for numerical work 
Author Message
 Fortran vs. C for numerical work


Quote:
>> [...]
>> The essential reason why I get repelled fortran, dusty decks
>> in fortran and the mindset of traditional (read: went to graduate
>> school before 1975) fortran programmers is the terrible
>> look-and-feel.  [...]

>You are right in changing the subject line.  This has little to do
>with the Fortran vs. C debate.  Especially since the look-and-feel
>of C is much worse for the problem domain appropriate to Fortran.

>> [...]           Beautiful (read: efficient on my time)
>> programming comes with a rich appreciation of how algorithms +
>> data structures makes programs, in careful attention to the way
>> modules interact, in fine-tuning the scope and visibility of data
>> across modules, in building really reuseable modules with sterile
>> interfaces, etc.  [...]

>You are thinking of programming as only a self-directed activity.
>If _you_ are the only end user, then your time is the only human
>efficiency consideration.  Most programmers are concerned with
>providing a useful capability for a large set of end users (including
>themselves).  The effect of a slow program on those end users is
>too complicated to be simple measured by the additional CPU time
>cost.  If a program takes an hour to run, I will use it differently
>(and less flexibly) than if it takes only a few minutes to run.
>Fast calculations are changing the way people work in all sorts
>of problem domains.  Fast simulations, for example, allow designers
>to iterate several ideas through the code (basing each new try on
>the results of the previous one) and are improving the design of
>everything from aircraft to computers.

>If there were a widely available language that allowed the programmer
>to do all the things you mention above and _still_ generated fast
>code, there would be no question about switching to it.  But the
>economics of computing still values speed over programmer time
>for most of the interesting problem domains.  The increase in
>raw speed of computers is not likely to change that much since
>this only expands the domain of viable problems to a larger
>set.  There are few problems for which code is already as fast
>as anyone will ever need.  End-user expectations rise as fast
>as the hardware improves.

>> [...]                                      I've seen
>> single-file-programs in fortran written two years ago (not the
>> dark ages of the 60s) of 10000 lines!  (not more than a few
>> hundred lines of comments, obviously).  That is disastrous, and
>> that is the essence of the problem to me.

>This is ambiguous.  A single file may contain any number of
>independent Fortran procedures (so your apparent assumption
>that the program in question is not modular is faulty).
>Further, you didn't tell us what the program _does_, so
>we can't determine whether 10000 lines is overly large or
>remarkably compact.  Complex problems require large programs:
>there is no "Royal road" to good programs.

>But, let us assume that you mean that the program was really a single
>procedure.  This still doesn't mean that it was disastrous.  It may
>have been carefully crafted using all the techniques that you support
>and _then_ all the procedure calls were "inlined" for speed.  This is
>not a bad technique - it will only disappear when "inlining" becomes
>a widely available feature of programming languages.  There is no
>a priori reason that Fortran could not be extended to do this (it is
>one of the things that Fortran Extended's 'internal' procedures should
>be able to do).

>In any case, I am in complete agreement that language designers
>should try to include features that promote more efficient coding
>and maintenance.  But so far, no language is widely available
>which does so AND is as efficient as Fortran-like languages.

This posting is the best argument presented so far in this argument, I believe.
I have included the whole posting so that one does not have to go back to find
out how the argument goes.

Tang



Fri, 21 May 1993 22:23:05 GMT  
 Fortran vs. C for numerical work
Are you all still arguing about C and Fortran?  The discussion
has gone from responding to a few inappropriate criticisms of C
(which was reasonable) to trying to downplay examples in which
Fortran might well be superior (which is silly) to discussing
multiplication vs. memory access time (which belongs in
comp.arch, if anywhere).

Quote:


>>Code maintenance is still better done on the Fortran.

>If you have to maintain the numerical libraries in FORTRAN, then you
>cannot really say that you are doing your numerical work in C.

Henry isn't saying you should do your numerical work in C, nor am I.
If your data structures are (as has recently been asserted) all
arrays, and you don't mind a few of Fortran's other weaknesses,
use it in good health.  C is better than a lot of people think it
is at numerical work, but it certainly isn't perfect, and C
apologists don't need to get up in arms when someone proposes an
example which Fortran can probably handle better.  Numerical work
has never been C's claim to fame, anyway.

                                            Steve Summit



Sun, 23 May 1993 09:52:54 GMT  
 Fortran vs. C for numerical work
Marc Roussel writes

Quote:
>     I am in graduate school in a very active research group.  Almost all
>of us use Fortran in this department, except for system administration
>and X-window programming.  I think that your comments underestimate the
>strength of Fortran.  Physicists, chemists and other natural scientists have
>different needs and interests than computer scientists.  Fortran suits
>many of these needs and will continue to be learned by natural
>scientists although I concede that computer scientists can now safely
>ignore it.  Fortran has returned to the niche for which it was originally
>intended.  Similarly, Cobol is no longer used to write OS's, but will
>probably continue to be used in business programming as it provides a
>natural interface in this environment.  (I know a lot less about Cobol
>than I do about Fortran usage... If Cobol is really dying, as the CS
>types are constantly assuring me, then you may ignore the last sentence
>of this paragraph.)

Absolutely!  

However, since languages are part of CS, and if there were enough CSists
around to convince people who have not made up their mind yet, we might
see a demise of Fortran.  

There is a growing trend towards using more elaborate data structures.
For example, discrete-particle simulations are frequently used in numerical
statistical mechanical systems, evolution of solid structures under random
growth environment (diffusion is really a random process).  In just these
two cases, sorting, and random access of elements are the likely to be the
most time-consumming tasks, Fortran may not be the appropriate language
(correct me if I am wrong).  

IMHO, these capabilities should be added to the
language (Fortran 90 may have them, I do not know much about F90) so that
there is no need to switch to a different language.  I would like to make
another point on the fomat of the program structure.  I like the fomat
of F77.  I know exactly where one line begins and ends without having to
search over the page for the semicolon.  Multiple line is not
a problem in F77 since you can always put a continuation sign at
the 6th column.  

Tang Wong



Tue, 25 May 1993 01:40:41 GMT  
 Fortran vs. C for numerical work

Quote:

>Marc Roussel writes
<<<deletions>>>

>However, since languages are part of CS, and if there were enough CSists
>around to convince people who have not made up their mind yet, we might
>see a demise of Fortran.

>There is a growing trend towards using more elaborate data structures.
>For example, discrete-particle simulations are frequently used in numerical
>statistical mechanical systems, evolution of solid structures under random
>growth environment (diffusion is really a random process).  In just these
>two cases, sorting, and random access of elements are the likely to be the
>most time-consumming tasks, Fortran may not be the appropriate language
>(correct me if I am wrong).

You *are* wrong, but you will have to correct yourself :-)

Quote:

>IMHO, these capabilities should be added to the
>language (Fortran 90 may have them, I do not know much about F90) so that
>there is no need to switch to a different language

Generalized data structures *are* in Fortran 90. In addition,
Fortran will continue to have more primary data types than
C (i.e. logical and complex).

-------------------+-------------------------------------------
Al Dunbar          |
Edmonton, Alberta  |  "this mind left intentionally blank"
CANADA             |          - Manuel Writer
-------------------+-------------------------------------------



Thu, 27 May 1993 02:51:44 GMT  
 
 [ 4 post ] 

 Relevant Pages 

1. Fortran vs. C for numerical work

2. Fortran vs. C for numerical work

3. Fortran vs. C for numerical work

4. C vs Fortran for numerical work

5. Fortran vs. C for numerical work

6. C vs Fortran for numerical work

7. Re : Fortran vs. C for numerical work

8. C++/FORTRAN for numerical work

9. Fortran vc. C for numerical work

10. Languages for Numerical Computation --- Was C vs FORTRAN

11. Different Numerical answers: VMS vs. Unix Fortran

12. Fortran vs C for numerical computation

 

 
Powered by phpBB® Forum Software