On Mar 26, 10:11 am, "Andy Dingley" <[EMAIL PROTECTED]> wrote: > On 26 Mar, 14:20, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote: > > > what are the advantages of using Python for > > creating number crunching apps over Fortran?? > > If you have to ask, you've not experienced enough Fortran to know its > sheer horror. > > You can write programs in Python that do usefully complicated things, > and you can get them to work in a reasonable time. Fortran can't do > this, for anything more than the trivial. "Classic" Fortran tasks of > the past are now seen as trivial. OK, so they did it to a lot of data, > but they really didn't do anything very complex to it.
You couldn't be more incorrect. I have run some very old (pre-Fortran 77) programs that are very far from trivial. > You can also write Python that other people can read and maintain. You > can't do this in Fortran, without a truly insane amount of trouble. This is a lie. I've seen some Fortran code that was hellspawned, and some that was clear as glass. The latter came about without a "truly insane amount of trouble". > As > Fortran programs have historically been authored and hacked on by > successive generations of grad students, this is the most vital > feature of all. Perhaps this is your impression because it's the only Fortran code you've ever been exposed to? > Finally we're no longer so interested in "number crunching". Number > crunching used to consist of simple operations over vast arrays of > data, although this was data with remarkably simple structure by > today's standards. These just aren't the major class of problems of > interest today. I suspect you're speaking from a narrow perspective, because "number crunching", as you define it, is still a problem of interest and heavily researched. Maybe it's not in your field. Anyways, you seem to be ignorant of the complexities of "simple operations over vast arrays", as if it you could accomplish these operations with a few lines of Python and numpy. That might be true for your homework, but good number-crunching codes often did a lot of stuff under the covers. > There's a massive difference between old-school FEA > (bashing Newton and Hooke into tinier and tinier cells) and > bioinformatics or anything involving the representation of big data > graphs. Ok, but exactly how do bioinformatics or big data graphs help you determine the stress profile in a beam? > > Python is a tad slower than Fortran > > If the Fortran program turns out to have been broken all along, then > who cares? That Fortran code is inherently broken is a pretty asinine thing to suggest. No one's under the impression that Fortran is a great, all- purpose language like Python is, but it does what it was designed to do well. When faced with a numerical problem, it's reasonable to consider using Fortran (especially knowing you can interface it with Python). Carl Banks -- http://mail.python.org/mailman/listinfo/python-list
