john@ghostwheel.unm.edu (John Prentice) (12/01/90)
In article <1990Nov30.163613.9562@alchemy.chem.utoronto.ca> mroussel@alchemy.chem.utoronto.ca (Marc Roussel) writes: > > ...When the time comes, I may >even ask some of you what language you think is appropriate. Until >then, I don't want your silly-ass opinion. If you want to compare >languages, do it on comp.lang.misc where someone cares ... > This is bunk in my opinion, and I happen to be a "fairly typical" Fortran programmer. Scientists cannot bury the head in the sand in a rapidly changing field like computation, no matter how much time it can take or how distracting it can be. It is exactly this kind of attitude that is the cause of so much of the garbage Fortran that is written. If these people were using C, it would probably be garbage C. Scientists need to be aware of these language issues and be receptive to new ideas. What are you doing to do when you find yourself writing code for a 64,000 processor Connection Machine? You may find that the choice of programming language makes a big difference. And the day is not far off that parallel machines are going to be where most scientific computation is going to be done. This news group strikes me as quite appropiate for these language discussions since it is read by exactly the audience most affected by these developments in computers. John Prentice Amparo Corporation john@unmfys.unm.edu
john@ghostwheel.unm.edu (John Prentice) (12/01/90)
In article <1990Nov30.163613.9562@alchemy.chem.utoronto.ca> mroussel@alchemy.chem.utoronto.ca (Marc Roussel) writes: > > I think I'm pretty typical of Fortran users... > ... Until >then, I don't want your silly-ass opinion. If you want to compare >languages, do it on comp.lang.misc where someone cares ... > Bunk. This kind of bull is one reason Fortran has a bad name, too many scientists who stick their head in the sand and ignore developments in computer science. I too am a "typical Fortran user" and I for one think that it is healthy to have debates such as this one. It allows people to see the virtues of other languages and maybe learn a little about something new. As to doing it in this news group, this one is read by scientists and I therefore think it is perfectly appropiate since it is exactly this audience that would best profit from knowing more about computer science. This is said, I would remind you, from the perspective of a computational PHYSICIST, not a computer scientist. I have to tell you, the world of scientific computing is changing and one's choice of language (be it Fortran, C, or whatever you like) may very well have to change with it. That is why I have found this discussion helpful, it has illuminated several points on both sides that I had not considered. Perhaps there should be a new newsgroup for scientific computation (or maybe one for ostriches), but I think this one is fine. John Prentice Amparo Corporation Albuquerque, NM john@unmfys.unm.edu
userAKDU@mts.ucs.UAlberta.CA (Al Dunbar) (12/02/90)
In article <1990Nov30.163613.9562@alchemy.chem.utoronto.ca>, mroussel@alchemy.chem.utoronto.ca (Marc Roussel) writes: > I think I'm pretty typical of Fortran users. I know Fortran and a >smattering of other languages. I use Fortran mostly because > > a) I can write code quickly in this language. > b) Compilers exist for it on any machine I'm ever likely to use. > > I don't want to use C. From what little I've been exposed to it, I >don't like it. C has a nasty syntax which I don't have time to learn. >Now everybody who's been trying to convince scientific programmers like >me to learn C, go away! Maybe you have the time to waste, but I don't. > Every algorithm I've ever used is expressible in Fortran. (I've >even written algorithms that create trees in Fortran using no >extensions other than recursion... That's right, no pointers, just good >old arrays.) If ever I run across a problem that I can't code in >Fortran, then I'll consider other languages. When the time comes, I may >even ask some of you what language you think is appropriate. Until >then, I don't want your silly-ass opinion. If you want to compare >languages, do it on comp.lang.misc where someone cares (notice the >followup-to line). Before this guy gets (justifiably) toasted in flames, it would be worth considering that part of the reason he holds such inflammable views is that there is a lot of language chauvinism on all sides of the "my language is better than yours" war. This is obviously part of our nature, as you could substitute "my religion" or "my skin colour" for "my language", and explain most of the world's problems. What is really unfortunate is, that this guy has formed an opinion about "C" without having the chance to be really objective about it. > Look, if someone out there can suggest a computer language that's >easy to learn and code in and that has the sort of widespread base that >Fortran does, I'll listen. C just isn't for scientific programmers >like me so it's no use trying to convince me (and probably 90% of the >rest of the readership of this group) otherwise. No one sensible would >say that Fortran is the best language for everything, but it's a more >than adequate language for most scientific computing. > While I'm at it, I sincerely hope that some cleaner language like >Turing wipes C off the face of this planet. I've about had it with all >this "my language is better than yours" garbage from the C folk and can >wish nothing for them other than extinction. > > Marc R. Roussel > mroussel@alchemy.chem.utoronto.ca If you don't like the "m.l.i.b.t.y" wars, why did you join in with such fervour? Give yourself a break and take the chip off your shoulder for a while. -------------------+------------------------------------------- Al Dunbar | Edmonton, Alberta | "this mind left intentionally blank" CANADA | - Manuel Writer -------------------+-------------------------------------------
wgh@ubbpc.UUCP (William G. Hutchison) (12/03/90)
In article <1990Nov30.163613.9562@alchemy.chem.utoronto.ca>, mroussel@alchemy.chem.utoronto.ca (Marc Roussel) writes: > > While I'm at it, I sincerely hope that some cleaner language like > Turing wipes C off the face of this planet. I've about had it with all > this "my language is better than yours" garbage from the C folk and can > wish nothing for them other than extinction. > > Marc R. Roussel > mroussel@alchemy.chem.utoronto.ca I inadvertently touched off one of these FORTRAN-vs-C wars about 2 years ago so let me apologize now for that one. I have learned a bit since then, so I offer my current perspective: (1) C is a lousy language for numerical work. (2) FORTRAN is a lousy language for anything BUT numerical work. (3) Both C and FORTRAN are lousy in that they facilitate writting highly bebugged code. I think that the main reason for such acrimonious debate is that neither side is qualified to express meaningful opinions, because both sides are lacking essential experience. In particular: (1) FORTRAN programmers mostly do not know how to do "data structure" programming and recursion, so they do not know what they are missing; (2) C programmers mostly work on micros, workstations, or minicomputers, so they are not acquainted with pipelining, vectorizing, parallel processing, etc., so they do not know what they are missing by using C. So what is one to do? I see at least two solutions: (1) Stop doing numerical work [ :-) ] (2) Find or develop a language suitable for this sort of work. Perhaps most practicioners would prefer solution (2) ??? I like your suggestion of Turing. Have you looked at Eiffel? I am also investigating Occam. Any opinions on this? -- Bill Hutchison, DP Consultant rutgers!cbmvax!burdvax!ubbpc!wgh (work) Unisys UNIX Portation Center uunet!eidolon!wgh (home) P.O. Box 500, M.S. B121 "At the moment I feel more like arguing than Blue Bell, PA 19424 being good" Raymond Smullyan _The Tao is Silent_
mccalpin@perelandra.cms.udel.edu (John D. McCalpin) (12/04/90)
>>>>> On 3 Dec 90 15:34:50 GMT, wgh@ubbpc.UUCP (William G. Hutchison) said:
William> I see at least two solutions:
William> (1) Stop doing numerical work [ :-) ]
William> (2) Find or develop a language suitable for this sort of work.
William> Perhaps most practicioners would prefer solution (2) ??? I
William> like your suggestion of Turing. Have you looked at Eiffel?
William> I am also investigating Occam. Any opinions on this? --
I have looked a bit at Turing and Turing-Plus. They are very nicely
designed languages, but do not have the constructs for the kinds of
abstraction that I would like. For example, they have neither
operator overloading nor class/object features. They *do* have a very
clean design that helps one program with fewer errors, but the style
of programming is much the same as with the traditional
Fortran/C/Pascal.
My interests right now are leaning more toward Modula-3, because of
its support for classes/objects. I am still trying to install it on
my IBM RS/6000 where its tendency to promote everything to double
precision actually causes codes to run faster instead of slower! I
have also not found enough tutorial/reference information to enable me
to get a really good feel for how to go about using Modula-3
effectively. I suppose that practice is the only teacher available
for the moment....
C++ is, of course, another possibility, but so far I have not seen any
C++ code that looks any easier to read or understand than the
equivalent C code -- though my lack of experience might be the
important factor here.
--
John D. McCalpin mccalpin@perelandra.cms.udel.edu
Assistant Professor mccalpin@brahms.udel.edu
College of Marine Studies, U. Del. J.MCCALPIN/OMNETgt4512c@prism.gatech.EDU (BRADBERRY,JOHN L) (12/04/90)
Ouch!!!!! Another satisfied customer! -- John L. Bradberry |Georgia Tech Research Inst|uucp:..!prism!gt4512c Scientific Concepts Inc. |Microwaves and Antenna Lab|Int : gt4512c@prism 2359 Windy Hill Rd. 201-J|404 528-5325 (GTRI) |GTRI:jbrad@msd.gatech. Marietta, Ga. 30067 |404 438-4181 (SCI) |'...is this thing on..?'
gt4512c@prism.gatech.EDU (BRADBERRY,JOHN L) (12/04/90)
The really sad thing about a lot of these kinds of debates is that many people are frustrated at the long 'learning curve' for C. Many who have programmed in other languages for years don't want to be forced to 're-think' their programming style to suit a language. However, the fact that one HAS programmed for years in a language is perhaps a good reason to take a step back and consider some alternative methods. It's too bad that it takes more time than many are willing to invest... -- John L. Bradberry |Georgia Tech Research Inst|uucp:..!prism!gt4512c Scientific Concepts Inc. |Microwaves and Antenna Lab|Int : gt4512c@prism 2359 Windy Hill Rd. 201-J|404 528-5325 (GTRI) |GTRI:jbrad@msd.gatech. Marietta, Ga. 30067 |404 438-4181 (SCI) |'...is this thing on..?'
poser@csli.Stanford.EDU (Bill Poser) (12/04/90)
Would someone care to enlighten me as to why he or she thinks that C has a difficult syntax and is difficult to learn? I just didn't have this experience, and I came to C after having learned Fortran, Assembler (MIX, on paper, and then the assembler for an obscure Japanese laboratory mini) and BASIC. I understand the position of LISP fans with respect to C syntax, since LISP syntax is clearly simpler (though I don't entirely agree that this is a good thing, but that's another issue), but why Fortran fans think that C syntax is more difficult is something that I find mysterious. As far as I can tell, the difficulties that people find in C stem from three sources: (a) C provides (via pointers and recursive functions) the ability to construct elaborate recursive data structures and the ability to traverse them. I suggest that the difficulties here are due to the fact that many programmers, especially Fortran programmers, are unfamiliar with data structures and recursion, but the problem is that these people need to learn these concepts, not a defect in the language. To make an analogy, most Algol-class languages lack closures, and people brought up on them may find it difficult at first to manipulate closures in a language like Scheme, but surely it is not a defect of Scheme that it provides them. (b) A few C constructs resemble constructs in other languages but are not the same. People brought up on these other languages don't like this. For example, gripes about the C switch statement seem basically to amount to the fact that it isn't the same as the Pascal case statement. (c) C doesn't provide run-time array bounds checking and some other safety features. I just don't see that this is that important. Surely it can be avoided by careful coding, and systems like Saber-C are available to do this at least at development time. But in any case, it isn't a syntax issue. In short, there are a number of modern language features that I like that C doesn't have, such as automatic storage allocation and garbage collection, closures, first class functions, out of band success/failure, and procedure suspension. These make me sympathetic to arguments for using languages like ICON and Scheme, at least for some purposes. But I really don't understand the arguments coming from Fortran enthusiasts. So, would someone care to explain why, from the point of view of Fortran, C can be said to have a complex syntax and to be difficult to learn? N.B.: I am aware of the efficiency arguments having to do with aliasing. That's a different issue. Bill
brnstnd@kramden.acf.nyu.edu (Dan Bernstein) (12/04/90)
In article <16671@csli.Stanford.EDU> poser@csli.stanford.edu (Bill Poser) writes: > Would someone care to enlighten me as to why he or she thinks that C has > a difficult syntax and is difficult to learn? I just didn't have this > experience, and I came to C after having learned Fortran, Assembler > (MIX, on paper, and then the assembler for an obscure Japanese laboratory > mini) and BASIC. I agree. I started by reading about Fortran II and IV and mainframe BASIC. Finally I had the actual experience of writing out some code (mainframe BASIC again) and giving it to someone to see results a week later. Then it was up through various assembler languages, MIX, Pascal, a fortunately brief stint with tiddlywink microcomputer languages, and now C. Somewhere along the line I picked up Forth, and had a lot more trouble with it at first than I ever had with C. It just isn't that hard a language to use, folks. Are you a Fortran prorgammer who wants to learn C the easy way? Promise yourself to spend five minutes a day putting your Fortran code through f2c and reading the results until you understand them. Past that you're home free. ---Dan
brnstnd@kramden.acf.nyu.edu (Dan Bernstein) (12/04/90)
In article <763@ubbpc.UUCP> wgh@ubbpc.UUCP (William G. Hutchison) writes: > (2) C programmers mostly work on micros, workstations, or minicomputers, > so they are not acquainted with pipelining, vectorizing, parallel > processing, etc., so they do not know what they are missing by using C. You may be right, but I doubt your generalizations apply to *numerical* programmers who happen to use C. I'd certainly feel quite restricted without the network facilities I use (from C) to handle large-scale parallel processing. And I regularly use a minisuper and a supermini with state-of-the art vectorizing and pipelining respectively. > (1) Stop doing numerical work [ :-) ] > (2) Find or develop a language suitable for this sort of work. > Perhaps most practicioners would prefer solution (2) ??? > I like your suggestion of Turing. Have you looked at Eiffel? I am also > investigating Occam. Any opinions on this? I've found C good enough. Why should I switch? ---Dan
wgh@ubbpc.UUCP (William G. Hutchison) (12/04/90)
In article <26349:Dec404:38:5790@kramden.acf.nyu.edu>, brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes: > In article <763@ubbpc.UUCP> wgh@ubbpc.UUCP (William G. Hutchison) writes: > > [ critical remarks about C programmers deleted ] > [ ... ] And I regularly use a minisuper and a supermini > with state-of-the art vectorizing and pipelining respectively. > I do not have a chance to work with this class of machine, so maybe you can help me. It is my impression that FORTRAN can do automatic vectorizing more easily than C because the FORTRAN loop and flow of control statements are so restricted (that surmise seems to be supported by other postings in this group). In C, on the other hand, my impression is that the programmer must do his/her vectorizing "by hand"; that compilers cannot do as much of the work automatically. If I am wrong on this point I would like to be corrected. Would you please post a page or so of a representative sample of your vectorized C so we can look at the coding techniques? Thanks! > I've found C good enough. Why should I switch? If you can handle it, go for it! > ---Dan Bill -- Bill Hutchison, DP Consultant rutgers!cbmvax!burdvax!ubbpc!wgh (work) Unisys UNIX Portation Center uunet!eidolon!wgh (home) P.O. Box 500, M.S. B121 "At the moment I feel more like arguing than Blue Bell, PA 19424 being good" Raymond Smullyan _The Tao is Silent_
mjs@hpfcso.HP.COM (Marc Sabatella) (12/05/90)
>But I really don't understand the >arguments coming from Fortran enthusiasts. So, would someone care >to explain why, from the point of view of Fortran, C can be >said to have a complex syntax and to be difficult to learn? I had the same experience as you - I learned BASIC, Fortran, Pascal, and three different assembly languages before learning C, and found the latter the simplest, syntactically. I think that is mainly because I had assimilated a basic understanding of semantics and learning one more syntax for well understood semantics was not a big deal. There are a few things a newcomer would consider "hard" about C, but of course in most cases, if you only plan to do Fortran-like things, you would never care. Pointers: Fortran doesn't have them, so they could confuse someone who has never seen one. Coming from a Pascal background, though, I had been frustrated at the lack of generality in its pointer scheme (you can't take the address of a variable? What about pointers to functions?) so C seemed a natural fix. To a Fortran programmer, thugh, jumping from no pointers to practically unrestricted pointers could be intimidating. If you could avoid pointers, this wouldn't be a problem, but you need them to implement pass by reference in C. So this is the next hurdle for Fortran programmers: understanding the distinction between value and reference. Pascal programmers have it easier in that it is more transparent, but at least going from Pascal to C, you have a basic understanding of how the two modes work, so it is pretty natural to translate syntax. Until you want to pass a pointer by reference, and start having to deal with pointers to pointers to... Scoping: Fortran has only the most primitive scoping constructs. With C, you get to deal with the overloading of the word "static", with "extern" declarations, and remembering when a declaration "char a[]" is interchangeable with "char *a" (function arguments) and when it is not (extern declarations). I/O: C's may be simpler to implement, but it can be intimidating to have 17 different functions, all of whose purpose is to read a few characters from a file. Loop constructs: why so many of them? The "for" statement is more generalized than your average numerical program will ever need. Assignment/conditional/post/pre/increment/decrement operators: you can avoid them if you want, but too often you see code that is rendered unreadable by overuse of these. Boolean operations: expressing them in numerical terms is an unnecessary (for most Fortran programmers) generalization. And why do you need parentheses around the "if" argument? Other things like having to declare variables before using them, etc - things we all take for granted, can seem like arbitrary syntactic restrictions to a Fortran programmer learning C.
turner@lance.tis.llnl.gov (Michael Turner) (12/05/90)
In article <26256:Dec404:30:1390@kramden.acf.nyu.edu> brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes: > >[C] just isn't that hard a language to use, folks. Are you a Fortran >prorgammer who wants to learn C the easy way? Promise yourself to spend >five minutes a day putting your Fortran code through f2c and reading the >results until you understand them. Past that you're home free. > >---Dan I guess what bothers me about this advice is that, if taken, it would increase the number of people who "know C"--but who really don't use much more semantics than FORTRAN already offers. I have had to debug large modules that were not much more than direct translations from FORTRAN to C, and have found it very frustrating. A typical problem is: float x[MAX_POINTS], y[MAX_POINTS]; where everything refers to the global arrays x and y, rather than defining typedef struct { float x, y; } point; and supplying a bunch of operations on "points", independent of a global data structure. This is not the best example. Perhaps a FORTRAN programmer could come up with a better way to encapsulate the concept of point in FORTRAN. I know, however, that I tried to write modular code in FORTRAN for many years, and never felt satisfied with the level of abstraction that I reached. Michael Turner turner@tis.llnl.gov
jwb@cepmax.ncsu.edu (John W. Baugh Jr.) (12/05/90)
In article <1183@ncis.tis.llnl.gov>, turner@lance.tis.llnl.gov (Michael Turner) writes: > A typical problem is: > > float x[MAX_POINTS], y[MAX_POINTS]; > > where everything refers to the global arrays x and y, rather than defining > > typedef struct { > float x, y; > } point; > > and supplying a bunch of operations on "points", independent of a > global data structure. But given the language capabilities (or lack thereof), what's so bad about this? One can adopt a convention that "points" are just "integers" (a la pointers) and provide all the operators one would expect to find on points (e.g., a primitive constructor, additional constructors like 'int pt_add(int p1, int p2)', observers, and so forth). Of course, the programmer has to keep track of what's "free" and what's "used" (or maybe write a little "storage allocator"). > This is not the best example. Perhaps a FORTRAN > programmer could come up with a better way to encapsulate the concept of > point in FORTRAN. I know, however, that I tried to write modular code > in FORTRAN for many years, and never felt satisfied with the level of > abstraction that I reached. Aside from the above, there may not be much else one can do--if FORTRAN doesn't support the linguistic features you want, you simply have to impose some conventions on the code you write. But don't listen to me, I haven't written a FORTRAN program in at least 10 years. > Michael Turner > turner@tis.llnl.gov John Baugh jwb@cepmax.ncsu.edu
brnstnd@kramden.acf.nyu.edu (Dan Bernstein) (12/05/90)
In article <764@ubbpc.UUCP> wgh@ubbpc.UUCP (William G. Hutchison) writes: [ vectorizing in Fortran versus C ] > In C, on the other hand, my impression is that the programmer must do his/her > vectorizing "by hand"; that compilers cannot do as much of the work > automatically. The Convex compiler easily recognizes all the standard loop idioms. With -va it treats all formal array parameters as unaliased; I've never had to use any directives other than this. > Would you please post a page or so of a representative sample of your > vectorized C so we can look at the coding techniques? Thanks! There's nothing really special... Here's a slightly interesting example. The compiler knows that x and y are unaliased. neg() is a vectorizable operation. #ifdef VECTOR for (i = 0; i < k; i++) y[i] = neg(x[i + r - k]); for (i = k; i < r; i++) y[i] = x[i - k]; for (i = 0; i < r; i++) x[i] = y[i]; #else for (i = 0; i < k; i++) y[i] = x[i + r - k]; for (i = r - 1; i >= k; i--) x[i] = x[i - k]; for (i = 0; i < k; i++) x[i] = neg(y[i]); #endif In this ANSIfied age I should set up a third version, like the second but based on memmove(); but I doubt that'll be faster than the first on most vector machines. ---Dan
mroussel@alchemy.chem.utoronto.ca (Marc Roussel) (12/05/90)
In article <16671@csli.Stanford.EDU> poser@csli.stanford.edu (Bill Poser) writes >Would someone care to enlighten me as to why he or she thinks that C has >a difficult syntax and is difficult to learn? Fortran has a relatively simple relation to mathematical formulae. You write the formula on paper and then transcribe it more or less directly into your program; this is especially true of Fortran 77 with it's intelligent type conversions and intrinsic function selection. The only thing Fortran 77 doesn't provide that naturally occurs in many algorithms is recursion, but many compilers handle recursion anyway. C on the other hand was not designed for math. It was designed for systems programming and any other use is incidental. It's not so much that C is difficult, it's that its syntax is unnatural for scientific programming. C is a lovely language if you're writing an OS. I think that those of us who say that we don't want to learn C because it's "difficult" really mean this: C is not particularly well-suited to our purposes so that beating our problem into C would be quite a chore. I also think that some of us (myself included) just generally object to languages that need braces, semicolons or other punctuation to make the meaning clear. If you want to see a language with equivalent functionality to C but with a much cleaner syntax, look at Turing. Marc R. Roussel mroussel@alchemy.chem.utoronto.ca
gl8f@astsun8.astro.Virginia.EDU (Greg Lindahl) (12/05/90)
In article <16671@csli.Stanford.EDU> poser@csli.stanford.edu (Bill Poser) writes: >Would someone care to enlighten me as to why he or she thinks that C has >a difficult syntax and is difficult to learn? Well, I found C much more difficult than Fortran, mainly because Fortran is totally trivial and with C you actually have to think about declaration verses allocation and worry a bit more about your pointers. Can't just turn on bounds checking to find goof-ups in loops. This isn't a major barrier to me, but I definately think Fortran is easier to learn, given that your problem fits what Fortran can do. > (a) C provides (via pointers and recursive functions) the > ability to construct elaborate recursive data > structures and the ability to traverse them. The programs I write these days don't need either. > (b) A few C constructs resemble constructs in other > languages but are not the same. C control structures have never bothered me. > (c) C doesn't provide run-time array bounds checking > and some other safety features. I just don't > see that this is that important. Surely it > can be avoided by careful coding, and systems > like Saber-C are available to do this at > least at development time. But in any case, > it isn't a syntax issue. It's sometimes very important during debugging. I don't own a copy of Saber C and I can't always afford the huge performance hit that it gives. Even if I had Saber C on one machine, I develop on a half-dozen (not that odd for an academic environment), and I don't have any money to spend on software. So I find it quite nice to have optional bounds checking. (The FSF is coming out with a "free" interpreter that will change the availablility situation, but it still may not be that fast.) All Joe/Jane Scientist wants is a simple language only complex enough to solve the problem, and yet be highly optimized. He/She wants it to be available on every machine, now and future, which s/he might use. It should be standard issue on all hardware and used by all of his/her friends. That language doesn't exist. But some languages come closer than others.
poser@csli.Stanford.EDU (Bill Poser) (12/05/90)
In article <1990Dec5.022302.25764@alchemy.chem.utoronto.ca> mroussel@alchemy.chem.utoronto.ca (Marc Roussel) writes: > > Fortran has a relatively simple relation to mathematical formulae. >You write the formula on paper and then transcribe it more or less >directly into your program; How is C so different? Neither C nor Fortran has much direct math support. Both have the basic operations in infix form. 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. I've never found it at all difficult to translate equations into C. The main difficulty is avoiding duplicate computation, and that has to be done explicitly in Fortran too.
karl@ima.isc.com (Karl Heuer) (12/06/90)
In article <8960029@hpfcso.HP.COM> mjs@hpfcso.HP.COM (Marc Sabatella) writes: >Boolean operations: expressing them in numerical terms is an unnecessary (for >most Fortran programmers) generalization. Not that this stops Fortran programmers from writing Y+C*(Y-X) when they want C?X:Y (and they "know" that .TRUE. is implemented as -1). >And why do you need parentheses around the "if" argument? Huh? Both C and Fortran need them, and for exactly the same reason. This is a reasonable question from a Pascal user, and the counter is "Why does Pascal need a THEN keyword?" Karl W. Z. Heuer (karl@ima.isc.com or uunet!ima!karl), The Walking Lint
mroussel@alchemy.chem.utoronto.ca (Marc Roussel) (12/06/90)
In article <16725@csli.Stanford.EDU> poser@csli.stanford.edu (Bill Poser) writes: >In article <1990Dec5.022302.25764@alchemy.chem.utoronto.ca> >mroussel@alchemy.chem.utoronto.ca (Marc Roussel) writes: >> >> Fortran has a relatively simple relation to mathematical formulae. >>You write the formula on paper and then transcribe it more or less >>directly into your program; > >How is C so different? Neither C nor Fortran has much direct math support. >Both have the basic operations in infix form. It's not just infix. Correct me if I'm wrong, but don't you have to declare every last variable in C? Given some relatively simple conventions and judicious use of implicit, you almost never have to declare a simple variable in Fortran. You also don't have to worry about which sqrt or log to use since the ANSI 77 standard. (Don't you have to do this in C? My impression was that C compilers, like F66 compilers, had to be told to use single precision functions here and double precision functions there.) >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? The same thing goes (doubly so!) for the complex type. If the 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. >I've never found it at all difficult to >translate equations into C. The main difficulty is avoiding duplicate >computation, and that has to be done explicitly in Fortran too. 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.) Look, I'm sure you don't mind this sort of thing, but I do. 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. C isn't a vegematic and I just get annoyed when someone tries to sell it to me as that. 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? Marc R. Roussel mroussel@alchemy.chem.utoronto.ca
robison@brazil (Arch D. Robison) (12/06/90)
> Fortran has a relatively simple relation to mathematical formulae. >You write the formula on paper and then transcribe it more or less >directly into your program; ... Have I missed the latest release of FORTRAN? The last time I tried to use differentiation operators, sparse matrices, set operations, big integers, power series, or quaternions, the FORTRAN compiler was rather confused. When I want to transcribe mathematical formulae, I use Mathematica. Arch D. Robison robison@shell.com
greg@sce.carleton.ca (Greg Franks) (12/06/90)
In article <26349:Dec404:38:5790@kramden.acf.nyu.edu> brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes: :-( Flame on the fortran flame wars :-( first he tries to tell fortran programmers to convert to C (r "read the output of f2c for 5 minutes a day" then says... > >I've found C good enough. Why should I switch? > >---Dan The fortran programmer is asking the same question. *** sigh *** Always use the tool most suitable for the job. Replies to alt.flame. -- Greg Franks, (613) 788-5726 | "The reason that God was able to Systems Engineering, Carleton University, | create the world in seven days is Ottawa, Ontario, Canada K1S 5B6. | that he didn't have to worry about greg@sce.carleton.ca ...!cunews!sce!greg | the installed base" -- Enzo Torresi
peter@ficc.ferranti.com (Peter da Silva) (12/06/90)
In article <1990Dec5.185852.5191@alchemy.chem.utoronto.ca> mroussel@alchemy.chem.utoronto.ca (Marc Roussel) writes: > It's not just infix. Correct me if I'm wrong, but don't you have to > declare every last variable in C? Given some relatively simple conventions > and judicious use of implicit, you almost never have to declare a simple > variable in Fortran. This is an advantage? The rest of your points are quite valid, and I get pretty defensive about the poor array support in C, but right now we're really just in a holding pattern waiting for the object oriented programming wars to get over and done with... and praying C++ doesn't win. Imagine if UNIX was written in Ratfor. -- Peter da Silva. `-_-' +1 713 274 5180. 'U` peter@ferranti.com
brnstnd@kramden.acf.nyu.edu (Dan Bernstein) (12/07/90)
In article <1990Dec6.144950.13182@ccs.carleton.ca> greg@sce.carleton.ca (Greg Franks) writes: > In article <26349:Dec404:38:5790@kramden.acf.nyu.edu> brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes: > :-( Flame on the fortran flame wars :-( > first he tries to tell fortran programmers to convert to C (r > "read the output of f2c for 5 minutes a day" then says... No, I didn't. I pointed out that a Fortran programmer who wanted to learn C the easy way could take advantage of f2c. Notice the adjective phrase beginning ``who.'' First Jim ignores ``packed'' in ``packed array trie.'' Then someone else ignores ``like C'' in ``Fortran does not have separate compilation like C.'' Then a dozen people ignore ``per byte'' and ``for sorting numbers'' in the sorting discussion. Now Greg can't read ``who wants to learn C'' after ``Fortran programmer.'' I know Mark Twain didn't think much of adjectives, but this is getting a little ridiculous. ---Dan
poser@csli.Stanford.EDU (Bill Poser) (12/07/90)
In article <1990Dec5.185852.5191@alchemy.chem.utoronto.ca> mroussel@alchemy.chem.utoronto.ca (Marc Roussel) writes: > It's not just infix. Correct me if I'm wrong, but don't you have to >declare every last variable in C? Given some relatively simple conventions >and judicious use of implicit, you almost never have to declare a simple >variable in Fortran. You also don't have to worry about which sqrt or log to >use since the ANSI 77 standard. (Don't you have to do this in C? My >impression was that C compilers, like F66 compilers, had to be told to >use single precision functions here and double precision functions there.) Yes, this is true, but I don't think of the need for declarations as an aspect of the syntax. Overloading of functions (e.g. sqrt) is indeed convenient. I'm not so sure about implicit declaration of variables. It saves typing, to be sure, but I suspect it is also a nasty source of bugs. Moreover, undeclared variables virtually never get commented, and most variables deserve a comment. >>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? The same thing goes (doubly so!) for the complex type. If the >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. I sort of agree about the complex type, though I think that this could be fairly easily solved by the inclusion of a standard complex class in a library (probably C++ rather than C). As for exponentiation, I think you are confusing two issues. I agree that it is pointless for everybody to write his or her own power function. That just means that it is something for which standard library functions ought to be available, as indeed they are. This is distinct from the issue of whether it is treated as an operator. The terminology here isn't 100% standard, so maybe we don't have the same notion of "operator". What I mean by "operator" is "function whose properties are known to the compiler". I think that this is a reasonable characterization of the typical usage. In some languages there is no ordering difference between operators and functions. Thus, by my definition LISP special functions are operators because the compiler/interpreter has to know not to evaluate their arguments. But they have the same ordering (prefix) as ordinary functions. In languages like C and Fortran the operators are infixed whereas ordinary function calls are prefixed and they are overloaded (e.g + adds both reals and ints). So, the differences between C and Fortran wrt to the power function do not, in principle, have to do with whether the individual programmer writes it or not, but rather with (a) whether it is overloaded (and this is not an issue in C++) and (b) whether it is prefixed or infixed. Personally, I don't care much about the latter, though I know some people do. I figure that if you do computations of much complexity you will need lots of functions in either language (and hence they will be prefixed), and that prefix or suffix notation makes complex expressions easier to read if they are well laid out. But I recognize that infixation of the power function is typical mathematical usage and hence that a language that does it this way is more comfortable for some people. >>I've never found it at all difficult to >>translate equations into C. The main difficulty is avoiding duplicate >>computation, and that has to be done explicitly in Fortran too. > > 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.) No, you can use array subscripting notation for an array argument in C. Suppose you have the following simple function, which is declared as receiving a pointer to a float. You can pass it either an array of floats or a pointer to float since the former is converted to the latter by the rules you mention. Nonetheless, the array subscripting syntax is permitted. This is because it is equivalent BY DEFINITION to pointer arithmetic. That is, a[i] and *(a + i) are equivalent by definition; some compilers actually do this transformation explicitly float FindMax(array,length) float *array; int length; { int i; float max; max = array[0]; for(i = 1; i < length; i++){ if(array[i] > max) max = array[i]; } return(max); } >Look, I'm sure you don't mind this sort of >thing, but I do. 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. C isn't a >vegematic and I just get annoyed when someone tries to sell it to me as >that. 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? I never meant to argue that you should. My query has to do with why Fortran folks find C syntax so unpleasant and difficult. If Fortran is going a good job for you, that's fine. For the sort of things that you mention, I'm willing to believe that Fortran is fine. I do think, however, that there is a lot of programming done in Fortran that would be better done in other languages, or by programmers acquainted with concepts that are more likely to be acquired through the study of other languages. For a fair amount of mathematical programming (I eschew the term "scientific programming" because it ought properly to cover much more than the narrow class of things it is applied to), the programming problems are fairly simple (from the point of view of sophistication of data structures and control structure) and the hard work is the numerical analysis. Fortran is probably fine for this kind of thing. But when instead of solving ODEs you are writing a time series editor or a visualization program or something like that, Fortran arguably becomes a straightjacket and a "systems programming" language like C can be a big help. Bill
mathew@mantis.UUCP (mathew) (12/07/90)
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
poser@csli.Stanford.EDU (Bill Poser) (12/07/90)
In article <EI+7GC7@xds13.ferranti.com> peter@ficc.ferranti.com (Peter da Silva) writes: > >Imagine if UNIX was written in Ratfor. Well, I don't know if that is a fair comparison to C++. Anyhow, if you want to see a big complex program that IS written in Ratfor, among other things, look at the sources for S (the statistics/graphics language from Bell Labs). S has lots of good ideas, but the source is gross. I remember installing it on a VAX 11/750 running 4.2BSD UNIX. The 4.2 f77 compiler didn't work so you had to install a hacked version of the 4.1 compiler. To make S you needed the newer version of the m4 macro processor, which wasn't distributed with 4.2. It was on the S dist tape, but there were no instructions telling you to install it. Etc. When you finally got everything figured out, with all of that preprocessing it took something like 12 hours to compile.
pcg@cs.aber.ac.uk (Piercarlo Grandi) (12/07/90)
Note: this posting may look like a flame. Unfortunately it is not. It is a dire and stern warning. Think over it over and over again if you think you have reason to disagree. On 5 Dec 90 02:23:02 GMT, mroussel@alchemy.chem.utoronto.ca (Marc Roussel) said: mroussel> Fortran has a relatively simple relation to mathematical mroussel> formulae. Hahahahahahahahaha! If only it were that easy. Ever heard of problems with associativity for example? I am very sure that the relation of Fortran to mathematical formulae is a very difficult and subtle and highly counterintuitive one, and that a lot of research has gone into the past to map some of its simpler aspects, or to work around the more difficult ones that are too difficult for us to understand. mroussel> You write the formula on paper and then transcribe it more or mroussel> less directly into your program; this is especially true of mroussel> Fortran 77 with it's intelligent type conversions and mroussel> intrinsic function selection. This is one of the tragedies of Fortran, that it traps people that do not understand about computers to think they do. Anybody who is good at maths thinks he/she is by God'a gift a good numerical analyst too. Doesn't Fortran give you real numbers, mathematical formulas, and familiar looking syntax? Fortran == maths! Frankly, a lot of mathematical research with computers is entirely meaningless because of this ridiculous delusion. Me, I am not a numerical analyst, but I know enough about computers to understand that numerical computing is a minefield of very difficult problems, and that the least of them is having a familiar notation that is utterly misleading (a+b in Fortran has completely different semantics from, only very remotely similar to, the semantics of a+b in maths). I hope that people like the guy above read the famous (evidently not enough!) paper on how to find the real roots of 2nd order polynomial equations (ax^2+bx+c=0) by computer (I cannot remember the author now -- Dekker maybe -- but I remember the paper is looong and difficult) and be ashamed (yes, ashamed) for ever having thought that the resemblance of Fortran's notation with maths is anything more than a honey trap for the unwary. What are the good languages for numerical research then? Sadly, Fortran is so preminent, precisely because it deceives the unwary about the immense chasm between maths and numerical computing, that I cannot think of any other similar low level language. I'd venture to say that as things stand probably Scheme is currently the best language for numerical analysis (if you think I am joking, think it over again *very* carefully), or some of the newer language with abstraction facilities, like C++. -- Piercarlo Grandi | ARPA: pcg%uk.ac.aber.cs@nsfnet-relay.ac.uk Dept of CS, UCW Aberystwyth | UUCP: ...!mcsun!ukc!aber-cs!pcg Penglais, Aberystwyth SY23 3BZ, UK | INET: pcg@cs.aber.ac.uk
kinnersley@kuhub.cc.ukans.edu (Bill Kinnersley) (12/08/90)
Parkinson's Law: The vehemence with which an issue is debated
is inversely proportional to its importance.
--
--Bill Kinnersleytony@oha.UUCP (Tony Olekshy) (12/08/90)
In message <EI+7GC7@xds13.ferranti.com>, peter@ficc.ferranti.com (Peter da Silva) writes: > [...] but right now we're really just in a holding > pattern waiting for the object oriented programming wars to get over and > done with... and praying C++ doesn't win. I agree with Peter here. Since C is the language so much system software is written in C, C tends to be the first stable language on a machine. Therefore, to beat competitors to market, you get an edge if you can build everything your application needs with nothing more than the compiler and your C source. I too am waiting for a replacement, perhaps something will come of the Eiffel consortium. I may even consider C++ for some processes, if they seem to be a natural fit. But if C's shortcommings are the problem, C++ is not the answer. -- Yours etc., Tony Olekshy. Internet: tony%oha@CS.UAlberta.CA BITNET: tony%oha.uucp@UALTAMTS.BITNET uucp: alberta!oha!tony I am afraid humility to a genius is as an extinguisher to a candle.--Shenstone
jlg@lanl.gov (Jim Giles) (12/08/90)
From article <PCG.90Dec7150237@odin.cs.aber.ac.uk>, by pcg@cs.aber.ac.uk (Piercarlo Grandi): > [...] > I hope that people like the guy above read the famous (evidently not > enough!) paper on how to find the real roots of 2nd order polynomial > equations (ax^2+bx+c=0) by computer (I cannot remember the author now -- > Dekker maybe -- but I remember the paper is looong and difficult) and be > ashamed (yes, ashamed) for ever having thought that the resemblance of > Fortran's notation with maths is anything more than a honey trap for the > unwary. By this argument, computational notation should be as different as possible from standard mathematical notation. It is not true though. The purpose of a programming language is _not_ to pander to the unwary. The purpose is to provide a convenient tool with which to construct executable representations of algorithms. For this purpose, the closer the language notation is to the corresponding notation used in the problem domain, the better. Bizarre, peculiar, idiosyncratic notation (such as is common in C) is just an impediment. Fortran is far from being too close to mathematical notation: it is not close enough. It is, however, as close as the charcter set of those early times allowed. It is certainly closer than C (and this is one of the factors in Fortran's favor). J. Giles
john@ghostwheel.unm.edu (John Prentice) (12/08/90)
In article <PCG.90Dec7150237@odin.cs.aber.ac.uk> pcg@cs.aber.ac.uk (Piercarlo Grandi) writes: > > ...one of the tragedies of Fortran, that it traps people that do >not understand about computers to think they do. Anybody who is good at >maths thinks he/she is by God'a gift a good numerical analyst too. > >Doesn't Fortran give you real numbers, mathematical formulas, and >familiar looking syntax? Fortran == maths! > >Frankly, a lot of mathematical research with computers is entirely >meaningless because of this ridiculous delusion. Me, I am not a >numerical analyst, but I know enough about computers to understand that >numerical computing is a minefield of very difficult problems, and that >the least of them is having a familiar notation that is utterly >misleading (a+b in Fortran has completely different semantics from, only >very remotely similar to, the semantics of a+b in maths). > Well, I AM a numerical analyst and while not minimizing the difficulty of some numerical techniques, this paragraph is a wild exaggeration. How about some supporting evidence instead of just opinion? As far as Fortran's relationship to mathematical notation, I don't think this has anything to do with why people fail to comprehend numerical methods. In fact, the problem people have in misusing numerical methods is not their programming for god's sake, it is their MATHEMATICS. An example, people in the flow in porous media community routinely apply finite difference techniques to solve PDE's using extremely long and skinny cells (in 2d). I have seen alot of 2 dimensional calculations with cells of 1 cm tall and 1 km wide. Yet the finite difference schemes are only accurate to some order of the largest cell dimension (in that community, they are usually only 1st order to boot - ugh!). That means the kilometer size dominates the error, except in circumstances where the flow is actually one dimensional. Now, people don't seem to appreciate this fact. Are you telling me it is because Fortran misled them? > >What are the good languages for numerical research then? Sadly, Fortran >is so preminent, precisely because it deceives the unwary about the >immense chasm between maths and numerical computing, that I cannot think >of any other similar low level language. > A bold claim from a non-numerical analyst. And I suppose if some hydrologist codes the same finite difference scheme I just referred to in C (or Scheme or whatever) instead of Fortran, divine elightenment will happen and he will see that he is making serious mathematical mistakes? Come on, this argument is ridiculous. And if you aren't a numerical analyst, why the sense of outrage? John Prentice Amparo Corporation Albuquerque, NM USA
templon@copper.ucs.indiana.edu (jeffrey templon) (12/08/90)
In article <16671@csli.Stanford.EDU> poser@csli.stanford.edu (Bill Poser) writes: >Would someone care to enlighten me as to why he or she thinks that C has >a difficult syntax and is difficult to learn? I just didn't have this Well, I will try. I like you did not have any trouble with C, no real trouble anyway, except perhaps with file i/o which is quite different than fortran (this is on a vax/vms system) - i still don't understand really how to open a file so i can write to it and open it at some later date (i gave up after about a day of trying, and have never used C for anything except stdio-type stuff (reading from terminal or redirected input.) since. the problem i think most fortran-scientific-types have with C is that it is 'economic in expression' to misquote k&r. constructs like b = sqrt( a < 0 ? -a : a) look very strange to a fortran programmer, compared to IF ( a .lt. 0.0) THEN b = sqrt(-1.0*a) ELSE b = sqrt(a) ENDIF most scientific types use computers in very brute-force ways, we're not interested in impressing customers with slickness, etc., so what's taught are brute-force, simple techniques like the fortran language and the EDT editor (on VMS). i got GNU Emacs working at our site about two years ago, and i can count on one hand the number who use it (about 100 or so use EDT though.) it just looks too fancy, too complicated, and it's something new, and well if you start learning something new, when are you going to stop? this is the mindset. they just don't want to know. they know how fortran works, and don't want to have to learn something new where unpredictable things will happen. there are 'legitimate' reasons too, however, why fortran programmers want to stick with fortran for numerical-intensive programs (at least under vax-vms). one is the huge amount of well-debugged code already written. nobody wants to rewrite and test a routine for computing racah coefficients in C when there is already one working in fortran. another reason (vms-specific) is that vms C uses the CALLS instruction to jump to a subroutine, as compared to fortran using CALLG. CALLS needs to build the argument list dynamically, at run time, for each subroutine call, while CALLG relies on the compiler having built the arglist and providing the its address. so when fortran calls a subroutine, the current context is saved, the pointer to the argument list structure is pushed on to the stack, and bang! you are in the subroutine. for CALLS, each argument has to be pushed onto the stack, and this takes enough time to be of concern if you have some program (like a monte-carlo simulation) which does a lot of subroutine calls. this is one reason why i chose fortran over C when i wrote my simulation program, even though coding the data structures and writing the parser for the geometry loader was much more difficult in fortran than it would have been in C. i just needed it to run fast, since i was anticipating calculations that would take hours on a vax 8650. fortran can get away with this because it does not have recursive subroutines. jeff
templon@copper.ucs.indiana.edu (jeffrey templon) (12/08/90)
In article <1990Dec5.185852.5191@alchemy.chem.utoronto.ca> mroussel@alchemy.chem.utoronto.ca (Marc Roussel) writes: > It's not just infix. Correct me if I'm wrong, but don't you have to >declare every last variable in C? Given some relatively simple conventions >and judicious use of implicit, you almost never have to declare a simple >variable in Fortran. You also don't have to worry about which sqrt or log to This is very very dangerous. It is probably one of the worst features of Fortran. If your compiler supports 'implicit none', i suggest that you make that line 2 of every program you write. we had a big simulation code running to help in designing an experiment; we put in some parameters to simulate misalignments of some of the apparatus with respect to other parts. based on varying these parameters, we found there to be no effect due to misalignment. well, we did not pay so much attention to it, and it did matter. a year later when i was rewriting the code, i found that the parameters and been called geoffx and geoffy when used in the calculation, and ge0ffx and ge0ffy when set to whatever value. FORTRAN in its infinite wisdom decided to set the geoffx and geoffy parameters to zero for us, regardless of the ge0ffx and ge0ffy input values. jeff
poser@csli.Stanford.EDU (Bill Poser) (12/08/90)
In article <8258@lanl.gov> jlg@lanl.gov (Jim Giles) writes: >Bizarre, peculiar, idiosyncratic >notation (such as is common in C) is just an impediment. > >Fortran is far from being too close to mathematical notation: it is >not close enough. It is, however, as close as the charcter set of >those early times allowed. It is certainly closer than C (and this >is one of the factors in Fortran's favor). Jim, if you'll read the past 20 messages or so you'll see that this is precisely one of the things we've been discussing. I have already asserted that neither C nor Fortran provides much direct math support, that to the extent that they do the notation is very close to mathematical notation, and that the only real difference that I can see is that in Fortran power is an infix operator as is typical in mathematics whereas in C it is a function and therefore prefixed. This is an awfully small difference, isn't it? So instead of naked assertions like the one quoted, how about some evidence and examples? And remember, we're talking about mathematical expressions, not aliasing, and not declaration syntax.
jlg@lanl.gov (Jim Giles) (12/09/90)
From article <X2uRT4w163w@mantis.UUCP>, by mathew@mantis.UUCP (mathew): > [...] > 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. I tend to agree. If such a different language were widely available, I would recommend using it. But, LISP is too slow (so far) and requires a different mind-set to use effectively (so: more retraining costs). And other rich languages for numerical programming (like Ada) are not widely available yet (and unproven - Ada has a reputation of being too large and complex - although this reputation mostly derives from comments by people who have no direct experience with Ada). But, your comment doesn't have anything to do with the Fortran vs. C debate. In fact it applies with even more force to C. I am not convinced that there's anything you can do with C gracefully. J. Giles
Bruce.Hoult@bbs.actrix.gen.nz (12/09/90)
In article <X2uRT4w163w@mantis.UUCP> mathew@mantis.UUCP (mathew) writes: >With C++, you can even define an infix notation for pow, and write things >like a = b toThe c; Not within the language, you can't. C++ lets you attech user-defined functions to infix operators, but the operator symbol must already exist in the language. Your "toThe" isn't allowed. You *could* use the above example if you did a #define so that "toThe" was replaced by a standard operator symbol, but that might get confusing. -- Bruce.Hoult@bbs.actrix.gen.nz Twisted pair: +64 4 772 116 BIX: brucehoult Last Resort: PO Box 4145 Wellington, NZ
Bruce.Hoult@bbs.actrix.gen.nz (12/09/90)
In article <77124@iuvax.cs.indiana.edu> templon@copper.ucs.indiana.edu (jeffrey templon) writes: >the problem i think most fortran-scientific-types have with C is that it >is 'economic in expression' to misquote k&r. constructs like > > b = sqrt( a < 0 ? -a : a) > >look very strange to a fortran programmer, compared to > > IF ( a .lt. 0.0) THEN > b = sqrt(-1.0*a) > ELSE > b = sqrt(a) > ENDIF That's a turn-around! I forget the exact syntax (haven't used FORTRAN for a decade), but can't you do this in FORTRAN? IF(a) 1111,1112,1113 1111 b = sqrt(-1.0*a) GO TO 1114 1112 b = 0 GO TO 1114 1113 b = sqrt(a) 1114 CONTINUE > another reason (vms-specific) is that vms C uses the CALLS instruction >to jump to a subroutine, as compared to fortran using CALLG. CALLS needs >to build the argument list dynamically, at run time, for each subroutine >call, while CALLG relies on the compiler having built the arglist and >providing the its address. so when fortran calls a subroutine, the current >context is saved, the pointer to the argument list structure is pushed on >to the stack, and bang! you are in the subroutine. for CALLS, each argument >has to be pushed onto the stack, and this takes enough time to be of concern >if you have some program In C or Pascal you could allocate a structure as a global (static) variable, assign your parameters into it and just pass a pointer to the structure to the called routine. The compiler might even be smart enough to use CALLG, but in any case the CALLS will be much faster pushing only one parameter. -- Bruce.Hoult@bbs.actrix.gen.nz Twisted pair: +64 4 772 116 BIX: brucehoult Last Resort: PO Box 4145 Wellington, NZ
jeenglis@alcor.usc.edu (Joe English Muffin) (12/10/90)
Bruce.Hoult@bbs.actrix.gen.nz writes: >In article <77124@iuvax.cs.indiana.edu> templon@copper.ucs.indiana.edu (jeffrey templon) writes: >> IF ( a .lt. 0.0) THEN >> b = sqrt(-1.0*a) >> ELSE >> b = sqrt(a) >> ENDIF >That's a turn-around! I forget the exact syntax (haven't used FORTRAN for a >decade), but can't you do this in FORTRAN? > IF(a) 1111,1112,1113 >1111 b = sqrt(-1.0*a) > GO TO 1114 >1112 b = 0 > GO TO 1114 >1113 b = sqrt(a) >1114 CONTINUE Sure, you can also do this in C: if (a < 0.0) goto label1; else if (a > 0.0) goto label2; else if (a == 0.0) goto label3; else exit(1); label1: b = sqrt(1.0 * -a); goto label4; label2: b = sqrt(1.0 * a) ; goto label4; label3: b = sqrt(1.0 * 0.0); goto label4; label4: ; What's your point? Personally, I'd be much more likely to use b = sqrt(fabs(a)); or B = SQRT(ABS(A)) in either case. Just a matter of style, I guess. >> another reason (vms-specific) is that vms C uses the CALLS instruction >>to jump to a subroutine, as compared to fortran using CALLG. >In C or Pascal you could allocate a structure as a global (static) variable, ^^^^^^^^^^^^^^ To allow recursion, the compiler would have to allocate this as 'auto,' in the caller's stack frame. >assign your parameters into it and just pass a pointer to the structure to >the called routine. The compiler might even be smart enough to use CALLG, ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Probably not. Since there's always the possibility that the function will be called from somewhere without a prototype in scope, parameter block argument passing wouldn't be a feasible scheme. --Joe English jeenglis@alcor.usc.edu
templon@copper.ucs.indiana.edu (jeffrey templon) (12/10/90)
In article <1990Dec9.040635.12696@actrix.gen.nz> Bruce.Hoult@bbs.actrix.gen.nz writes: >That's a turn-around! I forget the exact syntax (haven't used FORTRAN for a >decade), but can't you do this in FORTRAN? > > IF(a) 1111,1112,1113 >1111 b = sqrt(-1.0*a) > GO TO 1114 >1112 b = 0 > GO TO 1114 >1113 b = sqrt(a) >1114 CONTINUE Yeah, you could, but I wouldn't recommend it. Not many FORTRAN programmers I know do this anymore, at least if they are writing new code as opposed to modifying old code. If this was all you could do in fortran (maybe it is in fortran 77, but vax fortran allows if-then-else) then I would agree that there was real reason to migrate to C. >In C or Pascal you could allocate a structure as a global (static) variable, >assign your parameters into it and just pass a pointer to the structure to >the called routine. The compiler might even be smart enough to use CALLG, >but in any case the CALLS will be much faster pushing only one parameter. Defeats the purpose. The way it is with vms fortran, you just write a normal subroutine call. Easy. If I really wanted to trade extra work for speed, I'd write in assembler ... jeff
jlg@lanl.gov (Jim Giles) (12/10/90)
From article <1990Dec9.040635.12696@actrix.gen.nz>, by Bruce.Hoult@bbs.actrix.gen.nz: > [...] > In C or Pascal you could allocate a structure as a global (static) variable, > assign your parameters into it and just pass a pointer to the structure to > the called routine. The compiler might even be smart enough to use CALLG, > but in any case the CALLS will be much faster pushing only one parameter. Of course, copying the data into the globals might be a chore. And, putting all your data permanently into a global is probably not a good plan either. Now, Pascal doesn't allow separate compilation. So it _could_ use the faster call on those routines determined not to be recursive (which can be detected at compile time in Pascal). In C, the same trick _could_ be used, but only if you put all your procedures into the same source file. J. Giles
brnstnd@kramden.acf.nyu.edu (Dan Bernstein) (12/10/90)
In article <77124@iuvax.cs.indiana.edu> templon@copper.ucs.indiana.edu (jeffrey templon) writes: > the problem i think most fortran-scientific-types have with C is that it > is 'economic in expression' to misquote k&r. constructs like > b = sqrt( a < 0 ? -a : a) > look very strange to a fortran programmer, compared to [ the equivalent 5-line if-then-else in Fortran ] There is one big advantage to conciseness: readability. People often underestimate how important it is to have complete context on the same page. You have to balance this against the disadvantage of unfamiliar notations. For a C programmer, ?: is perfectly natural, so the above expression has the advantage of taking up less space without any disadvantages. ---Dan
john@ghostwheel.unm.edu (John Prentice) (12/10/90)
In article <1284:Dec1000:04:3190@kramden.acf.nyu.edu> brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes: > >There is one big advantage to conciseness: readability. People often >underestimate how important it is to have complete context on the same >page. You have to balance this against the disadvantage of unfamiliar >notations. For a C programmer, ?: is perfectly natural, so the above >expression has the advantage of taking up less space without any >disadvantages. > I would agree, up to a point. Conciseness can also be confusing, even to the initiated. Is it not true that there is an annual contest to write the most obscure working C code possible? And is it not further true that the usual winner has managed to be obscure through the use of conciseness? I still agree with your statement in general, but it can easily be taken to extremes. I have read a lot of German (East German, back when that meant something) mathematical papers that had so much economy of expression that they were virtually impossible to comprehend. One has to be very, very careful here. In either case, I would argue that conciseness is nearly always a disadvantage when you are just learning something, like a computer language. It may be okay once you have done it for a while, but it can really increase the time it takes to learn. You see this all the time when people try to learn C. All you have to do is read the C group and watch all the questions posted by the new programmers. John
Bruce.Hoult@bbs.actrix.gen.nz (12/10/90)
In article <13552@chaph.usc.edu> jeenglis@alcor.usc.edu (Joe English Muffin) writes: >> IF(a) 1111,1112,1113 >>1111 b = sqrt(-1.0*a) >> GO TO 1114 >>1112 b = 0 >> GO TO 1114 >>1113 b = sqrt(a) >>1114 CONTINUE > >Sure, you can also do this in C: > > if (a < 0.0) goto label1; > else if (a > 0.0) goto label2; > else if (a == 0.0) goto label3; > else exit(1); >label1: b = sqrt(1.0 * -a); goto label4; >label2: b = sqrt(1.0 * a) ; goto label4; >label3: b = sqrt(1.0 * 0.0); goto label4; >label4: ; > >What's your point? The point was that a FORTRAN user was complaining about the obscurity of the ? : construct in C, and I was pointing out tha tthe FORTRAN arithmetic GO TO wasn't much better. >>> another reason (vms-specific) is that vms C uses the CALLS instruction >>>to jump to a subroutine, as compared to fortran using CALLG. > >>In C or Pascal you could allocate a structure as a global (static) variable, > ^^^^^^^^^^^^^^ >To allow recursion, the compiler would have to allocate this >as 'auto,' in the caller's stack frame. I don't think you read the original posting. The point I was replying to was that in FORTRAN the compiler can generate more efficient code because there was no need to allow for recursion. My point was that if you disallow recursion then Pascal or C could do virtually as well. Your saying "To allow recursion, the compiler would have to..." is hardly a refutation of something which has assumed that recursion *isn't* happening. >>assign your parameters into it and just pass a pointer to the structure to >>the called routine. The compiler might even be smart enough to use CALLG, > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > >Probably not. Since there's always the possibility that the >function will be called from somewhere without a prototype in >scope, parameter block argument passing wouldn't be a feasible >scheme. I don't understand this remark. Could you explain it? -- Bruce.Hoult@bbs.actrix.gen.nz Twisted pair: +64 4 772 116 BIX: brucehoult Last Resort: PO Box 4145 Wellington, NZ
pcg@cs.aber.ac.uk (Piercarlo Grandi) (12/11/90)
In article <1990Dec8.024943.15468@ariel.unm.edu> john@ghostwheel.unm.edu (John Prentice) writes: john> In article <PCG.90Dec7150237@odin.cs.aber.ac.uk> pcg@cs.aber.ac.uk john> (Piercarlo Grandi) writes: pcg> ...one of the tragedies of Fortran, that it traps people that do pcg> not understand about computers to think they do. Anybody who is pcg> good at maths thinks he/she is by God'a gift a good numerical pcg> analyst too. pcg> Doesn't Fortran give you real numbers, mathematical formulas, and pcg> familiar looking syntax? Fortran == maths! pcg> Frankly, a lot of mathematical research with computers is entirely pcg> meaningless because of this ridiculous delusion. Me, I am not a pcg> numerical analyst, but I know enough about computers to understand that pcg> numerical computing is a minefield of very difficult problems, and that pcg> the least of them is having a familiar notation that is utterly pcg> misleading (a+b in Fortran has completely different semantics from, only pcg> very remotely similar to, the semantics of a+b in maths). john> Well, I AM a numerical analyst and while not minimizing the john> difficulty of some numerical techniques, this paragraph is a wild john> exaggeration. How about some supporting evidence instead of just john> opinion? It's not the difficulty, it's the profound difference which is pervasive. Just the fact that + has very different properties over the reals and over the floating points has profound and extensive consequences, and not just on the way code an algorithm, also on the how you design or choose the algorithm. The structure of algorithms built around the semantics of + on floating points very often does not in any way resemble the structure of algorithms that assume + over the reals. The (Dekker?) paper that I have mentioned takes a lot of pages to show you that in numerical analysis the dumbest way to solve "ax^2+bc+c=0" is to write +--------- | 2 -b + \| b + 4ac - x = ---------------- 2*a and then code subroutine solve2(a,b,c,x1,x2) discr = sqrt(b**2-4*a*c) x1 = (-b + discr)/(2*a) x2 = (-b - discr)/(2*a) return end and the reason is precisely because + and - have different semantics for floatings. Surely you don't use the mathematical definition of inverse of a matrix to compute the inverse; and surely even Gauss Jordan may not work too well, and you have to use power series expansions (which have the remarkable qualities that they invert by successive elevations to a power, i.e. multiplication, and thus are stabler and for certain machines much faster than Gauss Jordan). These are only two examples; solving stiff ODEs is a tricky business, and the coding techniques used have nothing to do with ODE maths. Even in symbolic computer algebra algorithms are completely different from those of "maths", even if the reasons for the difference are not the same as numerical analysis. Symbolic integration is certainly not done by parts, the Risch Norman symbolic integration algorithm is something that is about as alien from "maths" as the right way to solve numerically the 2nd order polynomial equation is. Exaggeration is IMNHO not; when you cannot even rely on the familiar properties of + and -, when it takes a long article to explain how to solve 2nd order polynomial equations, everything becomes suspect, paranoia becomes sanity. Floating point is weird, weird. Computer are weird, weird. (for mathematicians that is). john> As far as Fortran's relationship to mathematical notation, I don't john> think this has anything to do with why people fail to comprehend john> numerical methods. Well, again based on anectodal evidence, it misleads the unwary (that is those that are not coached hard in numerical analysis) into believing that Fortran == maths. As you say, this is a small problem, some people even fail to understand the properties of their algorithms, not just of computer algebra: john> In fact, the problem people have in misusing numerical methods is john> not their programming for god's sake, it is their MATHEMATICS. An john> example, people in the flow in porous media community routinely john> apply finite difference techniques to solve PDE's using extremely john> long and skinny cells (n 2d). I have seen alot of 2 dimensional john> calculations with cells of 1 cm tall and 1 km wide. Yet the john> finite difference schemes are only accurate to some order of the john> largest cell dimension (in that community, they are usually only john> 1st order to boot - ugh!). That means the kilometer size john> dominates the error, except in circumstances where the flow is john> actually one dimensional. Now, people don't seem to appreciate john> this fact. And they probably will fail to appreciate the fact that in all likelyhood they are mixing in the same calculations quantities with five or six orders of magnitude between them, and this may well cause problems with their floating point as well. As well. john> Are you telling me it is because Fortran misled them? No, even if examples of [censored] [censored] like this are all too common. But surely these [censored] also believe that Fortran == maths. The least of their problems, but probably (OK, I admit handwaving here!) it contributed. Certainly the major problem is poor mathematics, but the second major one is a failure to appreciate that maths and numerical analysis are quite different disciplines, just like theoretical and experimental physics, even if they have a common ground. But Fortran yes it does help to maintain the illusion that the common ground is much larger than it really is. Hey, however, would you believe that as a practical matter major computer manufacturers have had to provide floating point compatibility modes with the IBM/370 to sell their machines? What do you do when your customer says "My programs print 5.3E-15 on a 370 and 8.4E-15 on your machine, why does your machine get the result wrong by more than 50%"? Do you explain to them that the mantissa (if not the order of magnitude!) of the result printed by their program with which they have published loads of paper is solely function of the rounding algorithms of the machine it runs on? Hey, no, you wanna keep the customer, so out goes base 2 mantissa with rounding, and in comes base 16 mantissa with truncation like the IBM 370, which gives the right results: IBM of course does it right. I have seen worried comments by people heavvy in computational physics that since everybody in that field is running the same codes, independent verification is no longer common, as wide circulation of codes also means wide criculation of the bugs and poor numerical aspects of some of those codes. pcg> What are the good languages for numerical research then? Sadly, pcg> Fortran is so preminent, precisely because it deceives the unwary pcg> about the immense chasm between maths and numerical computing, that pcg> I cannot think of any other similar low level language. [ ... but pcg> maybe scheme or C++ .. ] john> A bold claim Which claim? That there few alternatives to Fortran for implementation work in numerical analysis? Hard to dispute that, IMNHO. It is easier to dispute the rationale I give, because it looks so attractive to the unwary. OK, let me at least claim that it is a powerful, even if maybe not dominannt, attraction, as demonstrated bu a number of posters in this thread, who argue whether C or Fortran is better suited for numerical analysis by looking at whether one or the other looks more like maths notation, something I regard as quite irrelevant myself, and misleading as well. john> from a non-numerical analyst. Well, I call myself a non numerical analyst only because I am not presumptuous. Surely your hydrologists as per above call themselves "numerical analysts". Surely the guys above that said that their code gave the correct results on an IBM 370 called themselves "numerical analysts". Ah yes. john> And I suppose if some hydrologist codes the same finite difference john> scheme I just referred to in C (or Scheme or whatever) instead of john> Fortran, divine elightenment will happen and he will see that he john> is making serious mathematical mistakes? john> Come on, this argument is ridiculous. But it is not my argument! You are reducing it to absurdity yourself. The argument is that a misleadingly familiar notation can trap the unwary, not that an unfamiliar notation will automagically make them wary. Given that a language should not be preferred (or avoided) because of its familiar notation, things like Scheme can become attractive. Scheme has excellent performance (a little more work on compilers can yield MAClisp style ones I think), and it has inbuilt support for things like infinite precision numbers, rationals, ... that ought to be used far more in numerical analysis, but are not because Fortran does not have them. Scheme has also fairly powerful abstraction facilities, so that for example adding interval arithmetic (another thing that is not in Fortran, and thus ignored by many) is not that difficult, and it has also excellent exception handling and library facilities, and so on. It does not a familiar looking syntax, but nobody should care. john> And if you aren't a numerical analyst, why the sense of outrage? Because I can sympathize with my numerical analyst friends that would send to the wall [censored] like your hydrologists, or like the [censored] I met that complained about the results being wrong because different from those of an IBM 370. Having shot them, one would put them down in unmarked graves in unblessed land with a stake in their heart, because they are surely agents of the Adversary :-). Even I (and I only did a couple of years of quack numerical analysis fifteen years ago) can be outraged by the [censored] idea that computers ought to give the illusion that they can do maths, and that any mathematician can become an instant numerical analyst (Fortran) or symbolic algebrist (Mathematica). -- Piercarlo Grandi | ARPA: pcg%uk.ac.aber.cs@nsfnet-relay.ac.uk Dept of CS, UCW Aberystwyth | UUCP: ...!mcsun!ukc!aber-cs!pcg Penglais, Aberystwyth SY23 3BZ, UK | INET: pcg@cs.aber.ac.uk
salomon@ccu.umanitoba.ca (Dan Salomon) (12/11/90)
In article <16671@csli.Stanford.EDU> poser@csli.stanford.edu (Bill Poser) writes: >Would someone care to enlighten me as to why he or she thinks that C has >a difficult syntax and is difficult to learn? It is not that C's syntax is hard to learn, it is that C is tricky to use. To convince yourself of this, read Andrew Koenig's book "C Traps and Pifalls", and try to come up with and equal number of equally serious traps and pitfalls for FORTRAN. Your FORTRAN list will certaily not be empty, but it will not be as long or serious as the one for C. You can alse read the FAQ list in this news group, and compare it to the one posted in comp.lang.fortran. If there is no such posting in comp.lang.fortran (as I suspect) then try to come up with a similar set of questions yourself. -- Dan Salomon -- salomon@ccu.UManitoba.CA Dept. of Computer Science / University of Manitoba Winnipeg, Manitoba, Canada R3T 2N2 / (204) 275-6682
jeenglis@alcor.usc.edu (Joe English Muffin) (12/11/90)
Bruce.Hoult@bbs.actrix.gen.nz writes: >>>In C or Pascal you could allocate a structure as a global (static) variable, >> ^^^^^^^^^^^^^^ >>To allow recursion, the compiler would have to allocate this >>as 'auto,' in the caller's stack frame. >I don't think you read the original posting. The point I was replying to was >that in FORTRAN the compiler can generate more efficient code because there >was no need to allow for recursion. My point was that if you disallow >recursion then Pascal or C could do virtually as well. You wouldn't *need* to disallow recursion though (and if you did, it wouldn't be C anymore.) Instead of using a global static for the parameter block, the compiler could allocate parameter blocks for each called function in the caller's stack frame. Most of these could overlap in many cases, so the space requirements wouldn't be much higher than for the usual calling scheme. >Your saying "To allow recursion, the compiler would have to..." is hardly a >refutation of something which has assumed that recursion *isn't* happening. It's very difficult for the compiler to determine that there's no recursion going on. To use a static area for the parameter block, the compiler would have to be sure that 1) the called function doesn't call itself, or any other functions which call it, and 2) the compiler will have access to this information when compiling any other source units which call this function. You could add a compile time switch or a #pragma directive, but it seems of limited utility. Besides, it's just as easy to allocate the stack frame in the caller's local storage anyway. >>>the called routine. The compiler might even be smart enough to use CALLG, >> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >>Probably not. Since there's always the possibility that the >>function will be called from somewhere without a prototype in >>scope, parameter block argument passing wouldn't be a feasible >>scheme. >I don't understand this remark. Could you explain it? Actually, I was wrong. Ignore what I said :-) There *is* a problem with variadic functions like _printf_ under calling schemes where the callee deallocates the stack frame on return, but since the calling function would "own" the parameter block, it shouldn't matter how many formal arguments the callee takes, only the number of actual arguments. So the CALLG instruction sequence would work for C functions after all, unless I'm missing something else... The question now is: why DOESN'T the VMS C compiler do this? (It would probably work pretty well on 680X0 architectures, too; less so on 80*86s and not at all well on RISC machines.) --Joe English jeenglis@alcor.usc.edu
john@ghostwheel.unm.edu (John Prentice) (12/11/90)
In article <PCG.90Dec10214715@odin.cs.aber.ac.uk> pcg@cs.aber.ac.uk (Piercarlo Grandi) writes: << long discussion of the pitfalls of the dangers of naive numerical methods deleted >> Your points are extremely valid and well taken. I have absolutely no quarrel about the fact that scientists very often fail to comprehend the difficulties and dangers inherent in sometimes even simple numerical math. I don't think one can lay the blame on any particular computer language however. I have to agree that saying c=a+b probably misleads some people into thinking you get the same answer on the computer as you would "analytically", but what is the alternative? Beyond that, certainly Fortran can't be held singularly responsible for that. The syntax is the same in almost all languages. >john> As far as Fortran's relationship to mathematical notation, I don't >john> think this has anything to do with why people fail to comprehend >john> numerical methods. > >Well, again based on anectodal evidence, it misleads the unwary (that is >those that are not coached hard in numerical analysis) into believing >that Fortran == maths. As you say, this is a small problem, some people >even fail to understand the properties of their algorithms, not just of >computer algebra: Okay, I can accept this up to a point. It is certainly true finite precision arithmetic is quite different from infinite precision arithmetic. This can lead to problems that even the best numerical analysists do not yet comprehend (a good deal of non-linear dynamics research is tied up with this precise point!). However, why lay the blame on Fortran? Just because the originators designated the language Fortran, meaning "Formula Translation" ? That seems a bit strong to me I guess. How is something like C or Pascal any better? While not in any way denying any of your quite valid points about numerical methods, I don't think language designers can be held responsible for this situation. << after referring to an example I originally gave of poor application of numerical methods >> > >And they probably will fail to appreciate the fact that in all >likelyhood they are mixing in the same calculations quantities with five >or six orders of magnitude between them, and this may well cause >problems with their floating point as well. As well. > >john> Are you telling me it is because Fortran misled them? > >No, even if examples of [censored] [censored] like this are all too >common. But surely these [censored] also believe that Fortran == maths. >The least of their problems, but probably (OK, I admit handwaving here!) >it contributed. > >Certainly the major problem is poor mathematics, but the second major >one is a failure to appreciate that maths and numerical analysis are >quite different disciplines, just like theoretical and experimental >physics, even if they have a common ground. But Fortran yes it does help >to maintain the illusion that the common ground is much larger than it >really is. > Okay, maybe so. It is a sad statement about the quality of scientists using computers (not necessarily a wrong one, but a sad one). Still, why just Fortran? This is a problem with people not understanding numerical methods, not a problem with Fortran (or so it seems to me). Do you REALLY think Fortran promotes this sort of thing or is it just that it is the most popular language for scientists? If scientists start programming in language [..pick one..], I bet you would have the same problem. >Hey, however, would you believe that as a practical matter major >computer manufacturers have had to provide floating point compatibility >modes with the IBM/370 to sell their machines? What do you do when your >customer says "My programs print 5.3E-15 on a 370 and 8.4E-15 on your >machine, why does your machine get the result wrong by more than 50%"? > >Do you explain to them that the mantissa (if not the order of >magnitude!) of the result printed by their program with which they have >published loads of paper is solely function of the rounding algorithms >of the machine it runs on? Hey, no, you wanna keep the customer, so out >goes base 2 mantissa with rounding, and in comes base 16 mantissa with >truncation like the IBM 370, which gives the right results: IBM of >course does it right. > >I have seen worried comments by people heavvy in computational physics >that since everybody in that field is running the same codes, >independent verification is no longer common, as wide circulation of >codes also means wide criculation of the bugs and poor numerical aspects >of some of those codes. > No quarrel at all here, in fact we violently agree! >pcg> What are the good languages for numerical research then? Sadly, >pcg> Fortran is so preminent, precisely because it deceives the unwary >pcg> about the immense chasm between maths and numerical computing, that >pcg> I cannot think of any other similar low level language. [ ... but >pcg> maybe scheme or C++ .. ] Well, we have hashed this out above. However, I would again suggest that Fortran is getting the rap just because it is the most common language used for doing science, not because it is inherently bad. As I said earlier, I have no doubt that if all the C enthusiasts out there managed to convert the scientific world to C tomorrow (or if not C, you name it), then you would see the same problems. > >john> And I suppose if some hydrologist codes the same finite difference >john> scheme I just referred to in C (or Scheme or whatever) instead of >john> Fortran, divine elightenment will happen and he will see that he >john> is making serious mathematical mistakes? > >john> Come on, this argument is ridiculous. > >But it is not my argument! You are reducing it to absurdity yourself. >The argument is that a misleadingly familiar notation can trap the >unwary, not that an unfamiliar notation will automagically make them >wary. > My apologies if I misrepresented your position. My choice of wording was inappropiate, I am sorry. And yes, I can accept that familiar notation can trap the unwary, but what about all those people out there who know what they are doing? I would hate to give up the convience of saying c=a+b just to avoid some idiot failing to understand the limitations of computer arithmetic. > >Given that a language should not be preferred (or avoided) because of >its familiar notation, things like Scheme can become attractive. > >Scheme has excellent performance (a little more work on compilers can >yield MAClisp style ones I think), and it has inbuilt support for things >like infinite precision numbers, rationals, ... that ought to be used >far more in numerical analysis, but are not because Fortran does not >have them. Scheme has also fairly powerful abstraction facilities, so >that for example adding interval arithmetic (another thing that is not >in Fortran, and thus ignored by many) is not that difficult, and it has >also excellent exception handling and library facilities, and so on. It >does not a familiar looking syntax, but nobody should care. > I am not familiar with Scheme. Could you point me at a reference so I can learn about it? Thanks. > >Even I ... can be outraged by the [censored] idea that computers >ought to give the illusion that they can do maths, and that any >mathematician can become an instant numerical analyst (Fortran) or >symbolic algebrist (Mathematica). > I only wish you were in charge of my funding! I couldn't agree with you more and wish the powers that be understood this more. Piercarlo, I think we are probably violently agreeing throughout this argument. I don't think Fortran is specifically to blame and you apparently do, but so be it. However, your points about people underestimating the difficulty of numerical methods are ones that most numerical analysists would agree on I think. In fact, one of the bigger problems computational physicists (or computational scientists in general, no matter what their principal discipline) face is the fact that the field is highly interdisciplinary and requires understanding computers, mathematics, and physics (or whatever). That is a tall order and most people end up compromising on one or more of these fields. More importantly however is that computational physics is really a separate discipline, not just physics which happens to be done on a computer. Makes you feel a bit like neither fish nor fowl. Regards, John Prentice john@unmfys.unm.edu
jfr@locus.com (Jon Rosen) (12/11/90)
In article <13585@chaph.usc.edu> jeenglis@alcor.usc.edu (Joe English Muffin) writes: >Bruce.Hoult@bbs.actrix.gen.nz writes: > >>>>In C or Pascal you could allocate a structure as a global (static) variable, >>> ^^^^^^^^^^^^^^ >>>To allow recursion, the compiler would have to allocate this >>>as 'auto,' in the caller's stack frame. > ><stuff deleted> > >It's very difficult for the compiler to determine >that there's no recursion going on. ... Ah... it should be noted that PL/I (an often denigrated but in many ways superior language to both FORTRAN and C) solves this problem quite neatly... Routines may be declared RECURSIVE in which case automatic variables are allocated as part of a "frame" along with the appropriate register save areas. Any routine not so declared may not be used recursively and only one copy of local variables is created. This permits increased optimization by the compiler and also reduces performance degradation due to reallocation of local variables. Jon Rosen
mroussel@alchemy.chem.utoronto.ca (Marc Roussel) (12/12/90)
In article <X2uRT4w163w@mantis.UUCP> mathew@mantis.UUCP (mathew) writes: >Common Lisp's >great for numerical stuff... if only it were faster! Now that's an intriguing comment... I never thought of Lisp as a numerical language. What facilities does it provide? Marc R. Roussel mroussel@alchemy.chem.utoronto.ca
jeenglis@alcor.usc.edu (Joe English Muffin) (12/12/90)
mroussel@alchemy.chem.utoronto.ca (Marc Roussel) writes: >In article <X2uRT4w163w@mantis.UUCP> mathew@mantis.UUCP (mathew) writes: >>Common Lisp's >>great for numerical stuff... if only it were faster! >Now that's an intriguing comment... I never thought of Lisp as a >numerical language. What facilities does it provide? *EVERYTHING*. Common Lisp has a rich set of of primitive data types, including arbitrary-precision integers and rationals, plus a full set of numerical functions. All the numerical primitives are fully polymorphic, as in Fortran (a big win over C), and the data abstraction facilities are excellent (a big win over Fortran). The numerical facilities in Common Lisp are second only to those in APL among the most common languages (well, those that I know of anyway), including Fortran. Interpreted functions are still slow as mail, but it's possible to bring the level of optimization to near that of Fortran for compiled code. Unfortunately, most of the good Lisp compilers cost Big Bucks, and the runtime support required is usually so high that you still need lots of memory. --Joe English jeenglis@alcor.usc.edu
pcg@cs.aber.ac.uk (Piercarlo Grandi) (12/13/90)
On 11 Dec 90 06:56:16 GMT, john@ghostwheel.unm.edu (John Prentice) said:
john> In article <PCG.90Dec10214715@odin.cs.aber.ac.uk>
john> pcg@cs.aber.ac.uk (Piercarlo Grandi) writes:
john&pcg> [ ... crying on each other's shoulder about the extreme
john&pcg> naiveity of a lot of "numerical analysts" ... ]
john> And yes, I can accept that familiar notation can trap the unwary,
john> but what about all those people out there who know what they are
john> doing? I would hate to give up the convience of saying c=a+b just
john> to avoid some idiot failing to understand the limitations of
john> computer arithmetic.
Here you have a point -- but frankly I think that 'c=a+b' is not a great
convenience. Still, of my 2 alternative to Fortran, one, C++, is kind of
the ultimate in notational convenience; like Fortran [89]0, user defined
types, operators, ... Now that I think of it I think that one of the
very best languages for numerical analysis, with some of the very best
implementations, is Algol 68. Too bad it has almost faded away. My other
alternative is a bit less traditional:
pcg> Given that a language should not be preferred (or avoided) because of
pcg> its familiar notation, things like Scheme can become attractive.
pcg> Scheme has excellent performance (a little more work on compilers can
pcg> yield MAClisp style ones I think), and it has inbuilt support for things
pcg> like infinite precision numbers, rationals, ... that ought to be used
pcg> far more in numerical analysis, but are not because Fortran does not
pcg> have them. Scheme has also fairly powerful abstraction facilities, so
pcg> that for example adding interval arithmetic (another thing that is not
pcg> in Fortran, and thus ignored by many) is not that difficult, and it has
pcg> also excellent exception handling and library facilities, and so on. It
pcg> does not a familiar looking syntax, but nobody should care.
john> I am not familiar with Scheme. Could you point me at a reference so
john> I can learn about it? Thanks.
Well, there is an introduction to programming, Abelson & Sussman, that
uses Scheme as vehicle. I think that even clearly you do not need to
learn programming from scratch, seeing that book is the best way,
because the Scheme programming style is quite different from Fortran,
and looking at it as if a beginner can be most interesting.
Scheme is a Lisp dialect, more or less (hand waving here!) descended
from MAClisp. MAClisp and Scheme were strongly influenced by MACsyma,
which even if it was a symbolic algebra package, had substantial
numerical components, and was written in MAClisp. Numerical support in
Scheme is particularly strong; infinite precision numbers are included
in the base language (as well as rationals, but I do not think that this
was a good idea though). It is easy to add new operators and data types,
and to create high level functions that strongly resemble common
mathematical ones (e.g. summation). The syntax is unconventional, like
Lisp, but easily managed with structure sensitive editors.
It is well known that the MAClisp compiler for the PDP-10 generated code
at least as good as the DEC Fortran for the same machine, because it had
been tuned to support MACsyma. Existing Scheme implementations, even
those that generate C or directly machine code, are not as efficient,
even if usually pretty good. Many Scheme implementations support linking
in procedure written in more conventional languages like assembler, C or
Fortran.
Scheme is one of the most widely implemented languages, running on all
of the popular architectures, is well defined by a clear and concise
report, ...
One of my favourite Scheme implementations is T, from Yale. Another is
Scheme->C from the DEC WRL.
Scheme is discussed in comp.lang.scheme. Note: I am not a regular user
of Scheme, I usually use C, because most of my work is Unix kernel
hacking. On the other hand, I am going to write an OS kernel, and I am
seriously considering writing it in Scheme (or Algol 68!) instead of
C++. The *only* stumbling block, like for Algol 68, is my inability to
find an implementation with a *retargetable* compiler that also
generates code for the 386. I would then hack it not to use GC (bad for
a kernel, whre I can allocate everything nearly statically).
john> [ ... about computational physics lacking an established tradition
john> and academic respectability as a subject of its own ... ]
Well, this is not really languages, but so what? :-). I can console you
a bit by saying that physics itself was a bit in the same state three
centuries ago. Also, much of the important results of physics in the
last decade have been done by computational physicists. Things may well
be turning around. Hold steady!
--
Piercarlo Grandi | ARPA: pcg%uk.ac.aber.cs@nsfnet-relay.ac.uk
Dept of CS, UCW Aberystwyth | UUCP: ...!mcsun!ukc!aber-cs!pcg
Penglais, Aberystwyth SY23 3BZ, UK | INET: pcg@cs.aber.ac.ukprentice@hydra.unm.edu (Colston Chandler PHYSICS) (12/13/90)
In article <PCG.90Dec12181318@odin.cs.aber.ac.uk> pcg@cs.aber.ac.uk (Piercarlo Grandi) writes: > >....Still, of my 2 alternative to Fortran, one, C++, is kind of >the ultimate in notational convenience; like Fortran [89]0, user defined >types, operators, ... Now that I think of it I think that one of the >very best languages for numerical analysis, with some of the very best >implementations, is Algol 68. Too bad it has almost faded away. > Whatever did happen to Algol? You see alot of the old ACM algorithms programmed in it and it looked rather interesting. I can remember seeing satellite ephemeris programs written in it 20 years ago, but you never hear of it anymore. So how is C++ for scientific programming? In particular, what exactly does an OOPS language do for numerical programming? Also, do you (or anyone else) have any suggestions for a good language for doing numerical programming on a parallel computer? I am interested in fluid dynamic like codes, so I need to maximize performance. I am looking at domain decomposition problems where I may have somewhat unstructured grids. The recent C versus Fortran war has at least convinced me that I should look more seriously at least at C for such things. Is C++ or Ada better? > > ... (after a discussion of Scheme) ... >Scheme is one of the most widely implemented languages, running on all >of the popular architectures, is well defined by a clear and concise >report, ... > I will look up the reference you gave on Scheme. Sounds like something I should at least know about. > >john> [ ... about computational physics lacking an established tradition >john> and academic respectability as a subject of its own ... ] > >Well, this is not really languages, but so what? :-). I can console you >a bit by saying that physics itself was a bit in the same state three >centuries ago. Also, much of the important results of physics in the >last decade have been done by computational physicists. Things may well >be turning around. Hold steady! > I appreciate the support! By the way, you are right that my discussion about the lack of academic respectability (good way to put it) of computational physics is not really a subject for this group, but it IS in a way, in the sense that so much of the recent flame war between C and Fortran (which I certainly have done my part to fan) is fueled by the problems that computational scientists face in having to balance understanding of their principal discipline with an understanding of computers. One has to sympathize somewhat if they are resistant to learning new languages unless there is a major advantage. It is really hard to keep up with your principal discipline and still keep up with the rapid developments in CS. That is alot of why it may appear that the Fortran community is so entrenched. It is not that these people are stuck in the past, it is just that they already have their hands full and need more than one or two reasons to switch from Fortran to something else (these comments are really pointed at the newsgroup in general). I don't think this is something the bulk of the CS community really understands. On the flip side, too many scientists resist every learning to program worth a damn and they do often ignore the bulk of CS research. Here is a need for another interdisciplinary activity, explaining CS to non-CS oriented scientific community. For example, I am a member of the ACM and have received the Communications for years. Yet I don't have the foggest idea of what most of the articles are about. I doubt most readers of the Communications would understand the articles I read in Physical Review B either. BUT, I need computers to do my job, CS people don't need theoretical solid state physics to do theirs. Be that as it may, I still don't have time (or interest to be honest) to make sense of the jargon in alot of these articles. It is therefore hard to keep abreast of the CS developments that ARE of improtance. The same is true of languages. There really is a need in the scientific community for people to translate these things. Well, pardon my diatribe. These sort of issues tend to excite ones passions (as is evident from the past weeks of controversy!). John john@unmfys.unm.edu
mccalpin@perelandra.cms.udel.edu (John D. McCalpin) (12/13/90)
> On 13 Dec 90 08:49:16 GMT, prentice@hydra.unm.edu (john@unmfys.unm.edu) said: John> In article <PCG.90Dec12181318@odin.cs.aber.ac.uk> pcg@cs.aber.ac.uk (Piercarlo Grandi) writes: >....Still, of my 2 alternative to Fortran, one, C++, is kind of >the ultimate in notational convenience; like Fortran [89]0, user defined >types, operators, ... Now that I think of it I think that one of the >very best languages for numerical analysis, with some of the very best >implementations, is Algol 68. Too bad it has almost faded away. John> Whatever did happen to Algol? You see alot of the old ACM John> algorithms programmed in it and it looked rather interesting. What we obviously need is GNU-Algol-68, maybe shorted to gnugol, or even just gol. Any volunteers for the implementation? ------------------------------------------------------------------------ > ... (after a discussion of Scheme) ... >Scheme is one of the most widely implemented languages, running on all >of the popular architectures, is well defined by a clear and concise >report, ... John> I will look up the reference you gave on Scheme. Sounds like John> something I should at least know about. While you are looking at Scheme, you should probably also look at T. T is a variant of Scheme for object-oriented LISP-looking programming which was developed at Yale. I have read the report, but have not yet had any time to play with the language.... ------------------------------------------------------------------------- John> I appreciate the support! By the way, you are right that my John> discussion about the lack of academic respectability (good way John> to put it) of computational physics is not really a subject for John> this group, but it IS in a way, in the sense that so much of the John> recent flame war between C and Fortran (which I certainly have John> done my part to fan) is fueled by the problems that John> computational scientists face in having to balance understanding John> of their principal discipline with an understanding of John> computers. The same problems exist in my field (ocean modelling), but are probably even more acute. John probably gets in trouble by being called a "computer hacker", while I get in trouble by being called a "mathemetician" just because I pay too much attention to getting the right answer from the mathematics that goes into the computer models! After all, the only thing that matters is getting pretty pictures, right? On the "respectability" subject, I was at the Supercomputer Computations Research Institute at Florida State a few years back when they tried to get together degree program in "computational science". The plan eventually failed. From my limited exposure to the actual politiking, it seems that it failed because: (1) The narrow view of "computational science" looked like it was simply a specialization within the applied math department. (2) The broad view of "computational science" was seen to be too large to fit into a reasonable Ph.D. program. (3) None of the existing departments wanted to risk giving up any of their current or prospective graduate students to yet another competing department. ----------------------------------------------------------------------- -- John D. McCalpin mccalpin@perelandra.cms.udel.edu Assistant Professor mccalpin@brahms.udel.edu College of Marine Studies, U. Del. J.MCCALPIN/OMNET
pcg@cs.aber.ac.uk (Piercarlo Grandi) (12/21/90)
On 13 Dec 90 08:49:16 GMT, prentice@hydra.unm.edu (Colston Chandler
PHYSICS -- or John Prentice?) said:
prentice> In article <PCG.90Dec12181318@odin.cs.aber.ac.uk>
prentice> pcg@cs.aber.ac.uk (Piercarlo Grandi) writes:
pcg> ....Still, of my 2 alternative to Fortran, one, C++, is kind of
pcg> the ultimate in notational convenience; like Fortran [89]0, user defined
pcg> types, operators, ... Now that I think of it I think that one of the
pcg> very best languages for numerical analysis, with some of the very best
pcg> implementations, is Algol 68. Too bad it has almost faded away.
prentice> So how is C++ for scientific programming? In particular, what
prentice> exactly does an OOPS language do for numerical programming?
Well, there are plenty of fairly good quality numerical libraries for
C++. The benefits of OO programming for numerical analysis is that even
numerical problems often have fairly sophisticated structure, and OO
programming is good at describing and changing structure.
While it may be a major undertaking to change an existing program in
Fortran to use sparse instead of full matrixes, it is much less of a
hassle in OO languages.
Changing your program from single to double precision and
viceversa is trivial in any language with type declarations; with OO
programming it is also almost as trivial switching from straight
floating point to interval arithmetic or arbitrary precision integers.
C++ also gives fairly concise notation, and it is easier to see the
shape of an algorithm in C++ than in Fortran, because of the superior
data abstraction facilities provided.
Cleverly used, C++ is at least as efficient as Fortran, or even more so
(const, inlining, ...), and the famous aliasing/optimization problem can
be usually worked around by the use of compiler directives or explicit
temporaries (the better solution, it makes things more obvious). On some
popular machines you get better speed by translating Fortran to C/C++
then using the Fortran compiler directly. Note that many of the proposed
extensions to Fortran as in Fortran [89]x are already present in C/C++.
prentice> Also, do you (or anyone else) have any suggestions for a good
prentice> language for doing numerical programming on a parallel
prentice> computer? I am interested in fluid dynamic like codes, so I
prentice> need to maximize performance. [ ... ] Is C++ or Ada better?
Ah, this is some hard question. Very hard. C is essentially like Fortran
in this, in that compilers analyze the source to find opportunities for
parallelism, and rewrite the program... Trickery.
Sadly, the state of the art for micro-parallel (vector/SIMD) languages
is not that advanced. Some interesting research is being done with
functional languages, but I am skeptical on functional languages (too
long to explain why). Moreover current functional language
implementations are not numerically oriented.
For coarser parallelism there is Concurrent C/C++ and a number of thread
packages for C/C++. Also, Ada tasking, but there are precious few
implementation of Ada that map tasks on threads running on multiple
processors. *Lisp for the Connection Machine is a rarely affordable
alternative.
Yeah, now that I think of it, I can remember several thread libraries
for C/C++, some of them multiprocessing (different threads run on
different CPUs), but (of course) none for Fortran. Interesting.
pcg> Scheme is one of the most widely implemented languages, running on
pcg> all of the popular architectures, is well defined by a clear and
pcg> concise report, ...
prentice> I will look up the reference you gave on Scheme. Sounds like
prentice> something I should at least know about.
I would suggest having a look at T and Mul-T; T is an implementation of
(something that is nearly identicaly to) Scheme with a fairly good
optimizing compiler; Mul-T is the parallel version of T. I have used a
little bit T, and it is large but nice. I have not used Mul-T.
Incidentally, a good list with discussion of Scheme implementations is
in "arisia.xerox.com:/pub/scheme/scheme-implements.txt".
prentice> [ ... the difficulty for computational physicists have in
prentice> styaing tuned with CS progress like new languages ... ]
But this is problem that engineers and physicists have! Their main
subject is not maths, it is engineering or physics, but maths are a very
important part of their training, and those that do research in
engineering or physics have to keep very current in maths as well;
indeed they have made a number of contributions to maths.
Computer Science is this respect is like Mathematics, an abstract
discipline that is ancillary to many others. Learning a new language is
(well, should be) like learning a new method for doing eigenvalues for
an engineer or a physicist.
It is a pity that Computer Science itself does not have the traditional
respectability of Mathematics, so that people that delight in learning
new ways to tackle the eigenvalue problem do not delight in learning new
languages or programming technology.
Is this a problem with languages or other CS technology that is more
offputting than maths? No, I think, because while CS people do care (too
rarely!) about human engineering issues, e.g. in designing languages
that are descriptive and concise, maths people don't; most mathmatical
notation is horrid, and most theorems could often be drastically
simplified and streamlined both in exposition and substance. But people
are used to and put up with cryptic maths, while they make excessive
demands of CS.
Ahh. Maybe this is why people think that Fortran is like maths: it is
cryptic and ill structured... :-(.
--
Piercarlo Grandi | ARPA: pcg%uk.ac.aber.cs@nsfnet-relay.ac.uk
Dept of CS, UCW Aberystwyth | UUCP: ...!mcsun!ukc!aber-cs!pcg
Penglais, Aberystwyth SY23 3BZ, UK | INET: pcg@cs.aber.ac.uk