HEMMAT@kuhub.cc.ukans.edu (Mehrzad Hemmat) (11/09/89)
Fortran to Pascal (or TP) Convertor If you know of any such software, please let me know. Thanks.
ajayshah@aludra.usc.edu (Ajay Shah) (07/27/90)
(LONG!)
I saw a huge number of postings citing one or the other reason
given which Fortran is the best computing solution around. I'll
describe one experience here.. see what you think of it.
I started life writing fortran since the first course in
programming at school (IIT, Bombay, India) taught fortran-77.
They had a great home-made compiler (gee, how I loved it) which
did things like trap uninitialised variables and scream about
wrong number or type of parameters, so it was a great place to
start off programming. I fell in love with computers at first
sight; and wrote something like 10k lines of fortran within those
three months. You can say I know fortran intimately.
I learned pascal that december (fortran was the
fall semester), because everybody I knew who'd tried pascal had
never come back, and got hooked on serious data structures.
Later, of course, with turbo pascal, there was no turning back;
it was not just the superiority of language but also the lovely
environment.
Last year, I joined the RAND corporation where my research group
lives on large-scale maximum likelihood. On all three relevant
fronts: size of datasets, dimensions of parameter vector and
complexity of likelihood function, our work is cutting edge.
Before I arrived, every single job was done with a monolithic
fortran program.
FACT 1:
Just for kix, I wrote a maximum likelihood package one
night in Turbo Pascal. It took a week to make it totally
slick. My program is far more comfortable to use than the
fortran programs used at RAND, and does more in terms of
statistical computations supported. I used the Turbo
Numerical Methods toolbox; it had all the basic routines I
needed, I only had to write a few routines related to the
normal distribution by hand where I hand-translated public-
domain ratfor code.
I might be brilliant, but writing this in a week was
tremendous. I don't know of any experience where writing a
full MLE system in fortran has not taken a few months
atleast, this has to do (in a deep sense) with the clumsy data
structures and abstraction supported by fortran.
The fortran system is around 10k lines, the pascal is 3k
lines. I don't think these numbers are easily shrugged
off.
A lot of people doing scientific programming live in a daze where
mainstream computer science is for every other kind of
programming in the world; *they* only need to write fortran
programs without intelligence in data structures, etc. I think
that attitude is a sad mistake. Personally, I've found
tremendous gains in complexity control through "smart" data structures"
in every single program i've written.
FACT 2:
In the work I've done at RAND ever since, while I've not
been able to get my group off fortran, I've transformed the
character of computing with fortran using Unix tools. I
recently wrote a simulator where dynamic programming
problems are solved. The traditional fortran programer
would have written one monolithic program which did the
simulations, with some lousy interface. Instead, I have a
solution involving
a 150 line cshell script,
2 awk programs, one 100 lines and the other 50 lines,
one fortran program of 300 lines.
The first awk program parses a very convenient input file
and generates a cshell script whose
output is converted by the 2nd awk program into a gnuplot
script.
My grouse with the "fortran-style-programmer" lies in the way he
takes fortran to be the black-box solution to every computing
problem. There is something so myopic there, it really gets me
irritated talking with such a specimen. Instead of thinking in
terms of a huge space of possibilities where fortran programs are
one (pretty limited) option, there is the mentality of
approaching everything as a fortran program.
--
_______________________________________________________________________________
Ajay Shah, (213)747-9991, ajayshah@usc.edu
The more things change, the more they stay insane.
_______________________________________________________________________________
_______________________________________________________________________________
Ajay Shah, (213)747-9991, ajayshah@usc.edu
The more things change, the more they stay insane.
_______________________________________________________________________________jensting@skinfaxe.diku.dk (Jens Tingleff) (07/27/90)
ajayshah@aludra.usc.edu (Ajay Shah) writes: >(LONG!) [..] (nice article) I'm no fan of FORTRAN (hehehe, I'm only here to anoy you) either. For my master thesis I wrote a program that does contrained quadratic integer programming, where the cost and contraint functions rely *heavily* on data coded as sets. Once previously, a FORTRAN program had been written for this task. On our "IBM 370 VM/rfghj{lkjhg" computer this FORTRAN program executed our standard test in a mere four CPU-minutes. My first version (written in Modula-2) executed the same computation in 3.5 minutes *on-a-8-MHz-PC* The problem was, of course, data structure, in that the original FORTRAN program used arrays of INTEGERs as set data, testing for superset-relation in a DO loop. Modula-2 used bit-maipulations, supported in a small way by the hardware in the PC (but not in a big way, my sets where 64 elements large, hence a multiword representation was used by the compiler *transparantly*). Now, no-one ever claimed that the original FORTRAN program was optimal, but the fact that such terrible performance was obtained (by someone with a lot of experience in coding this particular algorithm) with FORTRAN is a living tribute to the, ahemm, futileness of coding in a language with insufficient data structuring. Jens Jens Tingleff MSc EE, Institute of Computer Science, Copenhagen University Snail mail: DIKU Universitetsparken 1 DK2100 KBH O "It never runs around here; it just comes crashing down" apologies to Dire Straits
gillett@ceomax..dec.com (Christopher Gillett) (07/27/90)
In article <11053@chaph.usc.edu> ajayshah@aludra.usc.edu (Ajay Shah) writes: ... >Last year, I joined the RAND corporation where my research group >lives on large-scale maximum likelihood. On all three relevant >fronts: size of datasets, dimensions of parameter vector and >complexity of likelihood function, our work is cutting edge. >Before I arrived, every single job was done with a monolithic >fortran program. > >FACT 1: > Just for kix, I wrote a maximum likelihood package one > night in Turbo Pascal. It took a week to make it totally > slick. My program is far more comfortable to use than the > fortran programs used at RAND, and does more in terms of > statistical computations supported. I used the Turbo > Numerical Methods toolbox; it had all the basic routines I > needed, I only had to write a few routines related to the > normal distribution by hand where I hand-translated public- > domain ratfor code. It's excellent that you were able to create a good application using Turbo Pascal, but is this really an effective comparison to FORTRAN? Personally, I'm a big fan of Borland, but I don't ever need to have the capability of moving code to a Cray, or a Convex, or some other reasonably large number cruncher. Yes, the days of 800 analysts using their tubes to hook up to a big central machine are long since past, but the need to crunch numbers using pretty substantial iron still exists. >A lot of people doing scientific programming live in a daze where >mainstream computer science is for every other kind of >programming in the world; *they* only need to write fortran >programs without intelligence in data structures, etc. I think >that attitude is a sad mistake. Personally, I've found >tremendous gains in complexity control through "smart" data structures" >in every single program i've written. > It seems that what you're really complaining about here is the abilities and practices of scientific programmers, not the language itself. You could write: "*they* only need to write C programs without intelligence in data structures, etc." just as easily. You are correct in that there are a lot of really huge FORTRAN programs, written in very strange ways, bouncing around the world. If you've ever seen some of the automobile simulators used by the car companies, you've seen FORTRAN applications consisting of anywhere from 500K .. 1E+06K lines of code. Some of these programs are well written, others are not. Your comments about "smart" data structures is well taken. In fact, it's so well taken that the emerging FORTRAN standard addresses it with the inclusion of structures, type, and the like. I haven't followed the standardization process since I left Absoft (AC/FORTRAN lives! :-) ), but it seems to me the committee was headed in the right direction with respect to modularization and more powerful notions of data representation. One thing that hasn't been mentioned much in defense of FORTRAN is the sheer weight of the existing applications. There are not too many companies willing to drop large amounts of money into rewriting software just because the language is old and lacks some of the expressiveness of newer languages. Nor are there a lot of programmers, scientists, or analysts who really want to crawl inside those huge programs to understand how to rewrite them. >Ajay Shah, (213)747-9991, ajayshah@usc.edu Just my $0.02.... /Chris k --- Christopher Gillett gillett@ceomax.dec.com Digital Equipment Corporation {decwrl,decpa}!ceomax.dec.com!gillett Hudson, Taxachusetts (508) 568-7172
reggie@dinsdale.paradyne.com (George W. Leach) (07/27/90)
In article <11053@chaph.usc.edu> ajayshah@aludra.usc.edu (Ajay Shah) writes: >I saw a huge number of postings citing one or the other reason >given which Fortran is the best computing solution around. I'll >describe one experience here.. see what you think of it. Many of these postings indicated that it is the best computing solution around for specific types of applications, the the best computing solution in general. [lots of stuff deleted] >My grouse with the "fortran-style-programmer" lies in the way he >takes fortran to be the black-box solution to every computing >problem. There is something so myopic there, it really gets me >irritated talking with such a specimen. Instead of thinking in >terms of a huge space of possibilities where fortran programs are >one (pretty limited) option, there is the mentality of >approaching everything as a fortran program. This is not limited to FORTRAN programmers. Substitute your favorite language for FORTRAN and you can find people who fit the mold. FORTRAN and C were both developed with certain types of applications in mind. Both were used as general purpose languages by a great many programmers. FORTRAN's attraction as a general purpose language is not as great as it was since C has gained so much popularity. But FORTRAN's original purpose dictates that it continue to be used. Often availability of a suitable implementation dictates the language that will be used. At other times it may be company policy or other factors such as taking into account who will maintain the code and what are the expectations of those programmers? Being too clever or employing too many different tools can have a negative impact as well. You may limit portability by using tools that are not universally available. There has to be a balance that is struck that takes into account all factors. George W. Leach AT&T Paradyne (uunet|att)!pdn!reggie Mail stop LG-133 Phone: 1-813-530-2376 P.O. Box 2826 FAX: 1-813-530-8224 Largo, FL 34649-2826 USA
ghm@ccadfa.adfa.oz.au (Geoff Miller) (08/01/90)
ajayshah@aludra.usc.edu (Ajay Shah) writes: >...I fell in love with computers at first >sight; and wrote something like 10k lines of fortran within those >three months. You can say I know fortran intimately. You might. I wouldn't. I've spent much of the past fourteen years writing and debugging FORTRAN and I wouldn't make that claim. >...Personally, I've found >tremendous gains in complexity control through "smart" data structures" >in every single program i've written. Agreed. However, (a) FORTRAN is now moving in that direction, and (b) this is still a function of programmer skill. A programmer who thinks about data structures, optimisation of array access and a host of other considerations will write better programs than someone who doesn't, and it doesn't matter what language they are writing in. >My grouse with the "fortran-style-programmer" lies in the way he >takes fortran to be the black-box solution to every computing >problem. There is something so myopic there, it really gets me >irritated talking with such a specimen. Instead of thinking in >terms of a huge space of possibilities where fortran programs are >one (pretty limited) option, there is the mentality of >approaching everything as a fortran program. >-- I'm still not sure what you mean by "fortran-style-programmer". If you have looked at any of the recent guides to FORTRAN style (such as the one David Levine put together late last year) you will see a heavy emphasis on modularity, maintainability and maximal use of utility libraries, which seems to fit very well with your approach. The other points about FORTRAN are that there is a well-defined standard, leading to portability, and that FORTRAN compilers are generally quite efficient. A few years ago I was working on one computer (not where I am now, incidentally) where the PASCAL compiler was so inefficient that we had to prohibit its use. Really, though, you have to look at any language in the context of what it was designed to do, because there is no such thing as the ideal general-purpose language (unless you are a believer in ADA?). Geoff Miller (ghm@cc.adfa.oz.au) Computer Centre, Australian Defence Force Academy