jlg@beta.lanl.gov (Jim Giles) (07/01/88)
In article <559@lanl.gov>, dph@lanl.gov (David Huelsbeck) writes: > Jim, I tend to think lisp looks more like mathematic syntax than > Fortran does. A small subset of Fortran looks a lot like arithmetic > but mathematics? > I don't have any mathematics texts that contain anything even remotely resembling LISP at all. I have never seen any lisp construct in any mathematics text. (I'm told that some, more esoteric, mathematics fields have lamda calculus as a notational base - but I don't have any of those.) > I don't seem to remember seeing any DO loops in my mathematics texts. Mathematics texts don't have flow control problems to deal with. As a result, they never invented a standardized syntax for it. The parts of Fortran which represent scalar mathematical expressions do a creditable job of keeping to traditional mathematical syntax. > Well, maybe in my numerical methods book but it also contained an > arithmetic-if-statement in an example of "good code". Anybody who > can defend the AIS should have no problem with x+=(p=foo(b)?++i:i--) > The converse is also true. Anyone who can defend x+=(p=foo(b)?++i:i--) should have no trouble with the arithmetic IF. The arithmetic IF is obsolete and is only maintained for backwards compatibility. I don't know anyone who uses it for new code. The above C code is still considered _good_ code? > If you want something that really looks like mathematics, with the > the for-all and the there-exists operators, and REAL subscripting and > superscripting try MODCAP. (sigplan notices years ago) > I always thought that was called MADCAP. It was invented here at the lab. The problem was not notational (real math syntax IS a good idea - consider MACSYMA). The problem was typographical - new keyboards and displays had to be built to use the language. For practical reasons, programming languages are usually limited to syntaxes that flatten out (or linearize) the math expressions. Subject to this constraint, the closer the syntax resembles real math, the better. Fortran certainly has a long way to go to meet this goal. C has further. And, for any given language, there may be compelling reasons that some types of mathematics can't be done. But, if a new data type or numerical structure is added to a language, the synyax should be chosen to carefully match existing notational conventions as closely as possible. If not, really _good_ reasons should be required. J. Giles Los Alamos
gwyn@brl-smoke.ARPA (Doug Gwyn ) (07/01/88)
In article <20509@beta.lanl.gov> jlg@beta.lanl.gov (Jim Giles) writes: >The parts of Fortran which represent scalar mathematical expressions >do a creditable job of keeping to traditional mathematical syntax. Yeah, like X = X + 1 SNARF(IY) = 2 * (ZZ ** 3 - FLOAT( IY )) / SQRT( 2.0 ) (Quick, was that an array assignment or a statement function definition?) Could this discussion of Fortran and "mathematical syntax" please be moved out of the C newsgroup? Better yet, could the whole "my language is better than yours" discussion cease? The original question was whether a particular shop should perform a wholesale conversion of existing Fortran code to C. A useful answer to such a question would have very little to do with which language is closest to mathematical syntax, whatever that is supposed to mean.
mike@arizona.edu (Mike Coffin) (07/01/88)
From article <20509@beta.lanl.gov>, by jlg@beta.lanl.gov (Jim Giles): > Mathematics texts don't have flow control problems to deal with. As > a result, they never invented a standardized syntax for it. The parts > of Fortran which represent scalar mathematical expressions do a > creditable job of keeping to traditional mathematical syntax. Hmmm. Plus, minus, divide, and parenthesis are used in pretty much the same way. In traditional mathematics, multiplication is usually represented by adjacency (sometimes a dot or a cross), square roots by a root sign, absolute values by vertical bars, complex numbers as in (3+4i), inequalties by < and > (not .LT. and .GT.), ... the list could be extended indefinitely. And at least one symbol, =, is used in a decidedly nontraditional way. (Can you imagine Gauss or Euler uttering "a = a + 1"?). I'm not saying this is all bad. In fact, you hit the nail on the head: mathematics texts don't have to deal with flow control, while programming languages (at least imperative ones) deal with almost nothing else. There has never been a standard way to present algorithms; often they end up as numbered steps interspersed with natural-language instructions. -- Mike Coffin mike@arizona.edu Univ. of Ariz. Dept. of Comp. Sci. {allegra,cmcl2,ihnp4}!arizona!mike Tucson, AZ 85721 (602)621-4252
g-rh@cca.CCA.COM (Richard Harter) (07/01/88)
In article <20509@beta.lanl.gov> jlg@beta.lanl.gov (Jim Giles) writes: >The converse is also true. Anyone who can defend x+=(p=foo(b)?++i:i--) >should have no trouble with the arithmetic IF. The arithmetic IF is >obsolete and is only maintained for backwards compatibility. I don't >know anyone who uses it for new code. The above C code is still >considered _good_ code? Ahem. There is actually a good reason for the arithmetic IF, albeit not in the style of fortran. Any time you compare two items with an order relationship you have three possible cases, 1st<2nd, ==, and 2nd>1st. The three way comparison is a very natural and common situation. The problem with the arithmetic IF is the use of statement numbers. In a more modern style one would use three blocks, e.g. compare(x,y) { lt: stuff if x less than y eq: stuff if they are equal gt: stuff if x greater than y } with ge, le, and ne covering the combined cases. The point is that the standard boolean IF is a two way switch; any method for converting a three way switch into two switches has its minuses. -- In the fields of Hell where the grass grows high Are the graves of dreams allowed to die. Richard Harter, SMDS Inc.
wes@obie.UUCP (Barnacle Wes) (07/05/88)
> In article <20509@beta.lanl.gov> jlg@beta.lanl.gov (Jim Giles) writes: > > ........................................... The arithmetic IF is > obsolete and is only maintained for backwards compatibility. I don't > know anyone who uses it for new code. I do. About 4 years ago, I was involved in a project that required writing several software tools. A friend was working on a CPU simulator for an odd little computer, to be used for testing the software that ran on the little beastie. In the design phase, it was calculated (somehow) that the finished simulator would have a simulation time - real time ration on the order of 12:1 to 20:1. This was on a VAX-11/780 with FPA. My friend used arithmetic if statements in that program; he even used (gasp!) computed gotos. The final run times were on the order of 3:1 - 4:1. Was it worth it? He thought so, I thought so. You decide. VAX Fortran seems to be pretty good at optimizing computed gotos, BTW. -- {hpda, uwmcsd1}!sp7040!obie!wes "Happiness lies in being priviledged to work hard for long hours in doing whatever you think is worth doing." -- Robert A. Heinlein --
rob@kaa.eng.ohio-state.edu (Rob Carriere) (07/07/88)
In article <77@obie.UUCP> wes@obie.UUCP (Barnacle Wes) writes: >[...] VAX >Fortran seems to be pretty good at optimizing computed gotos, BTW. VAX Fortran seems to be pretty good, period. I like Un*x much better than VMS, I prefer C over Fortran any day, but I *love* the VAX Fortran compiler! It is dependable, fast, produces code that is amazingly good, and it interfaces very well with its' environs. C compiler writers, please take note! Rob Carriere
walter@garth.UUCP (Walter Bays) (07/08/88)
In article <77@obie.UUCP> wes@obie.UUCP (Barnacle Wes) writes: >> ........................................... The arithmetic IF is >> obsolete and is only maintained for backwards compatibility. I don't >> know anyone who uses it for new code. > > I do. ... A friend was working on a CPU simulator My friend used > arithmetic if statements in that program; he even used (gasp!) computed > gotos. The final run times were on the order of 3:1 - 4:1. [As > opposed to 12:1 to 20:1 projected otherwise on a VAX-11/780 with FPA.] > Was it worth it? He thought so, I thought so. You decide. I think not. Keep the clearer, more maintainable code. Take one year's maintenance on the 780 and buy a new workstation to replace it. (It doesn't even have to be ours, though of course that's preferable :-) Then you get run times better than 3:1, and continue saving on both hardare and software maintenance. You may ask, "Didn't I ever write tricky code for speed when constrained to a particular hardware base?" Of course. "Did I ever write tricky code for speed when there was no compelling reason to?" Yes. I admit it. It's addictive. -- ------------------------------------------------------------------------------ My opinions are my own. Objects in mirror are closer than they appear. E-Mail route: ...!pyramid!garth!walter (415) 852-2384 USPS: Intergraph APD, 2400 Geng Road, Palo Alto, California 94303 ------------------------------------------------------------------------------
wes@obie.UUCP (Barnacle Wes) (07/10/88)
In article <895@garth.UUCP>, walter@garth.UUCP (Walter Bays) writes: > I think not. Keep the clearer, more maintainable code. Take one > year's maintenance on the 780 and buy a new workstation to replace it. > (It doesn't even have to be ours, though of course that's preferable > :-) Then you get run times better than 3:1, and continue saving on > both hardare and software maintenance. In general, I agree with you, but in this case, the speed was really needed. The hardware was firmly fixed - this was a government contract, and the computer was GFE - Government Furnished Equipment. End of argument about what to run it on. The CPU simulator was just a small part of a simulator for a particular type of powerful rocket with a very accurate guidance system (you can guess all you want what it REALLY was :-), and the rest of the simulation was written by physicists who readily admitted they were not good programmers. The overall simulation times were in the neighborhood of 100:1 to 250:1. When it takes 5 hours to simulate a 30-minute flight, every little bit of speed helps. It would not do to have the CPU simulator making it 3 or 4 times slower yet! The whole project would have been much better in the long run if they had added one good Fortran programmer to the physical body simulator - perhaps making it 2 or 3 times faster. -- {hpda, uwmcsd1}!sp7040!obie!wes "Happiness lies in being priviledged to work hard for long hours in doing whatever you think is worth doing." -- Robert A. Heinlein --