john@ghostwheel.unm.edu (John Prentice) (11/24/90)
Concerning the on-going Fortran vs C discussion, let's turn the problem around. Instead of C programmers defending C against Fortran, I would be curious to hear a discussion of what C has that is so lacking in Fortan, from the perspective of the scientific programmer, not the computer scientist. Most Fortran programmers are not particularly sophisticated, don't desire to be, and I don't see that they need to be. This is the advantage of Fortran, it is easy. On the other hand, my background IS with sophisticated codes (and very, very big ones requiring hundreds of hours of Cray time to run often). There are alot of things I don't like about Fortran, but frankly most of the features in C that people get so excited about are not ones I feel too deprived about not using (particularly given that Fortran 90 has alot of them). I am willing to be convinced that C is in some sense or another superior to Fortran, but so far nobody has done so. To be honest however, the whole debate seems a bit sterile. Use whatever language you want, they just aren't that different. John Prentice Amparo Corporation
jbc@hpcllmv.HP.COM (Jeff Caldwell) (11/24/90)
>Instead of C programmers defending C against >Fortran, I would be curious to hear a discussion of what C has >that is so lacking in Fortan, from the perspective >of the scientific programmer, not the computer scientist. Hmm... I can't really argue for the merits of C when you're limiting the conversation to scientific programming. I wouldn't really want to use C to create a heavy duty large number crunching application. Fortran would likely be better. I work at Hewlett Packard and currently write/maintain/enhance both the Fortran and C compilers for 4 different platforms (different machine types). I feel C is a much better language for sophisticated datatype/structure manipulation. It's ease of use of pointers and structures is unmatched by even the most robust implementations of Fortran. Fortran, on the other hand, allows you to do terribly perverse things to memory with the use of COMMON blocks and EQUIVALENCEs. You can't even begin to do some of the data overlapping and data disection in C that Fortran enables you to do. The defined support for COMPLEX datatypes is a good example of why Fortran is far superior for numerical applications. Of course, I haven't mentioned anything that is news to anyone. I guess the fact that I wouldn't want to write anything larger that a couple of hundred lines in Fortran but don't mind writing large applications in C says something for C. Jeff Caldwell | HP California Language Lab P.S. Both the Fortran and C compilers are written in C :-)
john@ghostwheel.unm.edu (John Prentice) (11/25/90)
In article <1270009@hpcllmv.HP.COM> jbc@hpcllmv.HP.COM (Jeff Caldwell) writes: > >I work at Hewlett Packard and currently write/maintain/enhance both the >Fortran and C compilers for 4 different platforms (different machine types). >I feel C is a much better language for sophisticated datatype/structure >manipulation. It's ease of use of pointers and structures is unmatched >by even the most robust implementations of Fortran. Fortran, on the other >hand, allows you to do terribly perverse things to memory with the use of >COMMON blocks and EQUIVALENCEs. You can't even begin to do some of the >data overlapping and data disection in C that Fortran enables you to do. I totally agree about the virtues of C for datatype/structure manipulation. But I cringe at the use of COMMON blocks and EQUIVALENCES in Fortran, even though I have used them to do the sorts of perverse memory handling you suggest (at least years ago). Nowadays I would say that there is little need for such things however, given the ability to do dynamic memory allocation either by linking to malloc or in Fortran 90. >Of course, I haven't mentioned anything that is news to anyone. I guess >the fact that I wouldn't want to write anything larger that a couple of >hundred lines in Fortran but don't mind writing large applications in C >says something for C. Perhaps, but are you programming numerical codes? The codes we develop average 50,000 to 100,000 lines of Fortran (probably half of that are comments however). If it is done with care, we have had minimal problems and we run the same code on everything from PC's to Crays to Connection Machines (though the CM2 does require some modification to exploit Fortran 90 array constructs). >P.S. Both the Fortran and C compilers are written in C :-) No question about that, but so? A compiler is not a numerical computation. John Prentice Amparo Corporation
Iain Holness <HOLNESSI@QUCDN.QueensU.CA> (11/26/90)
Different languages are suited for different problems.
First you get an algorithm, then a data structure, and
THEN you decide on the language. Otherwise you're operating
with tunnel vision before you start to code.
Of course, you can always do one-shot stuff in APL ! b-)
Iain3003jalp@ucsbuxa.ucsb.edu (Applied Magnetics) (11/27/90)
In article <1990Nov24.002836.19739@ariel.unm.edu> john@ghostwheel.unm.edu (John Prentice) writes: >... I would be curious to hear a discussion of what C has >that is so lacking in Fortan, from the perspective >of the scientific programmer, not the computer scientist... Numerical analysis _is_ different from computer science. You worry a lot about applied mathematics, e.g. numerical stability, convergence rates, error estimates (well, you should anyway). By the time you're ready to code, Fortran is just fine. Read the numbers, crunch the numbers, write the numbers. See the introduction to "Numerical Recipes in C" for more opinions. Having said this, there are cases where you wish for more. One of them is finite element analysis. The meshes are often "unstructured" and do not fit naturally in arrays like finite differences used to. You really want more advanced data structures. Still, finite element codes are often written in Fortran. Related to finite elements are sparse matrices, which don't naturally fit into arrays either. There are commercial sparse matrix packages; guess what they're written in? Fortran. On the other hand, you occasionally bump into complex numbers and you find that C doesn't have them. Writing complex arithmetic in terms of function calls is error-prone. If you have C++, you can go back to infix notation, but that brings us to the original issue of this thread: compiler adequacy to numerical analysis. Will the C++/C compiler optimize your complex arithmetic? it doesn't even know that complex addition is commutative. (Correct me if I'm wrong.) My own impression is that numerical analysis meant Fortran, until now. In the past couple of years, workstation vendors started to pay serious attention to floating-point performance. Compilers have improved, including C compilers. There is still room for improvement, though, especially in instruction scheduling. Many of the fast CPUs have pipelined floating-point; keeping the pipelines busy is tricky. --Pierre Asselin, R&D, Applied Magnetics Corp. I speak for myself.
boylanr@silver.ucs.indiana.edu (ross boylan) (11/27/90)
On the idea that we can program in C and call Fortran language subroutines: 1) The different conventions about which subsripts vary fastest (i.e., in ARRAY(A,B,C), does C or A vary fastest?) seem to make this extrememly tricky, unless the language interface does lots of time-consuming twiddling. My personal experience was with the PL/I interface to VS Fortran on an IBM mainframe, but I think similar issues apply to C. Is there a good solution? 2) You can only only convert libraries to C if source is available; IMSL is getting rather restrictive about this on their latest release. It is my impression that at least IMSL's code is tuned for particular machines and compilers; it seems unlikely a translation would be as effective. 3) In the case of the PL/I-Fortran interface, the overhead of cross-language calls was enormous (I recall I converted a 3 second pure Fortran program into a 60 second mixed-language, functionally equivalent program).
gl8f@astsun7.astro.Virginia.EDU (Greg Lindahl) (11/28/90)
In article <1990Nov24.002836.19739@ariel.unm.edu> john@ghostwheel.unm.edu (John Prentice) writes: >Concerning the on-going Fortran vs C discussion, let's turn the >problem around. Instead of C programmers defending C against >Fortran, I would be curious to hear a discussion of what C has >that is so lacking in Fortan, from the perspective >of the scientific programmer, not the computer scientist. Well, many Fortran programmers also know C, and some of us are fluent in quite a few languages. It's more a matter of picking the right tool for the right job than an argument between diametrically-opposed camps. My latest scientific coding project was a numerical hydrodynamics code. It has no need for data structures other than simple arrays. It has no need for dynamic allocation. It does need to be able to be compiled on a bunch of different scalar and vector architectures and run fast. So I chose Fortran. I would like to see structures in Fortran. I would like to see more compilers check subroutine/function argument types. But I don't want to see Fortran messed up such that I have to code register temporaries by hand for array elements that are used more than once in a loop. At the moment, that's what I think I'd need to get C to run as fast for some of my numerical stuff. So add structures but try to prevent people from using pointers too often. And that's what the F9x people tried to do. >To be honest however, the whole debate seems a bit sterile. Use whatever >language you want, they just aren't that different. Yup. But if you have a target machine in mind, or target machines, you should consider the relative quality of the compilers too.
jbc@hpcllmv.HP.COM (Jeff Caldwell) (11/28/90)
> Different languages are suited for different problems. > > First you get an algorithm, then a data structure, and > THEN you decide on the language. Otherwise you're operating > with tunnel vision before you start to code. > > Of course, you can always do one-shot stuff in APL ! b-) > > Iain I can see determining an algorithm first, but a data structure? I'd hate to implement a binary tree or sparse matrix in a language without pointers:-) The binary tree is possible with an array but that causes predefined limits on the size. Use of records/structures could pose a problem too. -Jeff Caldwell
hht@sarnoff.sarnoff.com (Herbert H. Taylor x2733) (11/29/90)
I would like to see this discussion move from "IS Fortran or C better" to "WILL Fortran or C BE better" in the future on emerging new architectures, particularly the massively paralel ones - both MIMD and SIMD. How do the efforts to respresent parallelism in C compare to those expressed by Fortran90? -- | |\/\/\/\/\/\/| --<>-- Herb Taylor (609) 734 - 2733 | | | __ |__ / /. DSRC, Subsidiary of SRI Int | | | ( .)(. ) /_ _/ . Parallel Computing Research | | \ ) \\ // <> email: herbt@apollo.sarnoff.com |
john@ghostwheel.unm.edu (John Prentice) (11/29/90)
In article <771@sarnoff.sarnoff.com> hht@sarnoff.sarnoff.com (Herbert H. Taylor x2733) writes: > >I would like to see this discussion move from "IS Fortran or C better" >to "WILL Fortran or C BE better" in the future on emerging new >architectures, particularly the massively paralel ones - both MIMD and >SIMD. How do the efforts to respresent parallelism in C compare to >those expressed by Fortran90? I will make the statement I made several times earlier during this debate. Neither Fortran nor C represent parallelism very well. Neither language was written with a modern parallel architecture in mind and I don't see that either is really very suitable. We need a new language for numerical parallel calculations. Particularly since I think there is little doubt that parallelism is going to be the the way scientists work in the future (at least at the cutting edge of scientific computing). John Prentice Amparo Corporation Albuquerque, NM
whit@milton.u.washington.edu (John Whitmore) (11/30/90)
In article <771@sarnoff.sarnoff.com> hht@sarnoff.sarnoff.com (Herbert H. Taylor x2733) writes: > >I would like to see this discussion move from "IS Fortran or C better" >to "WILL Fortran or C BE better" in the future ... Finally, a topic I can really get behind! Most languages have some constructs that allow optional arguments: OPEN(UNIT= the_unit, FILE='FileName',FORM='UNFORMATTED) is a Fortran example. Yet, this sort of 'keyword=value' calling sequence is not supported for user subroutines. The language implementors needed it; SO DO THE USERS. CALL READ_THE_FILE( file='FileName', & format='Bruce''s third generation data set', & into= data_array(5) ) In fact, I've written similar calls in some of my code, in Fortran, but it's terribly messy. One has to pass strings and pick out 'keyword=' strings and look at what follows 'em. Making the 'keyword=' optional requires *sigh* yet more coding, and the usual trauma of choosing a default. The calling module, of course, makes the string with a WRITE to some pre-allocated fixed length string variable. Secondly: DATA initialization requires that action be taken before a module is explicitly entered in the course of execution. Even more useful would be an entry point which was invoked only at startup of the image (so one could put any initialization code a module needs, INSIDE the module, with complete assurance that initialization would always precede any other executable code). Why stop there? Add a 'EXIT_HANDLER' entry point, so that any cleanup of buffers that a module needs, will be queued for execution when the image exits (for whatever reason). No more improperly closed files, or buffers left unflushed! Many language implementations have this already, of course, in somewhat clumsy form (at least in VMS). It's terribly useful, and there is no system-independent way to do it in FORTRAN (or C, to my knowledge). Surely, any reasonable operating system supports exit handlers? Third: it's damned near impossible to make an interactive program without building in some way to fork-to-shell (on VMS, I use a subprocess). This allows a program user to peruse his file directory for that name he'd forgotten how to spell, or read his notes, or send some quick E-mail. It's an essential part of interactive programming (IMHO), but has never been included in any system-independent way. Add this to the language definition! VMS and Unix have no problems with this sort of thing; even my Macintosh can do it. BUT I have to recode the program each time I port it! These rantings brought to you by John Whitmore whit@milton.u.washington.edu
gl8f@astsun7.astro.Virginia.EDU (Greg Lindahl) (12/01/90)
In article <11977@milton.u.washington.edu> whit@milton.u.washington.edu (John Whitmore) writes: > Third: it's damned near impossible to make an interactive >program without building in some way to fork-to-shell (on VMS, I >use a subprocess). [...] It's an essential part of >interactive programming (IMHO), but has never been included in >any system-independent way. Add this to the language definition! Why not just write a standard subroutine interface, CALL ZSPAWN for example, and then write a separate routine for each OS? No need to clutter up the language for something this simple. And you can slowly build a while library of Z-routines on a variety of platforms.