Re: Fortran vs Python - Newbie Question
Steven D'Aprano [EMAIL PROTECTED] wrote: On Mon, 26 Mar 2007 06:40:49 -0700, kyosohma wrote: Fortran also appears to be a compiled language, whereas Python is an interpreted language. Sheesh. Do Java developers go around telling everybody that Java is an interpreted language? I don't think so. What do you think the c in .pyc files stands for? Cheese? Well, I'm being a bit argumentative here, but it's hard to deny that the use of compiled in the context of .pyc (or .javac) is very different from the use of compiled in the context of running gcc. Once upon a time, Basic enthusiasts would have used the word tokenized to describe .pyc files. A .pyc file is, in fact, interpreted by an intermediate language interpreter. I don't understand why anyone would be embarrassed by that. Is it fast enough? It certainly is for MY needs. -- Tim Roberts, [EMAIL PROTECTED] Providenza Boekelheide, Inc. -- http://mail.python.org/mailman/listinfo/python-list
Re: Fortran vs Python - Newbie Question
Beliavsky [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] On Mar 26, 10:16 am, [EMAIL PROTECTED] (Cameron Laird) wrote: In article [EMAIL PROTECTED],[EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Is there a mac version?? Thanks Chris Yes. Several, in fact--all available at no charge. The Python world is different from what experience with Fortran might lead you to expect. Your experience with Fortran is dated -- see below. I'll be more clear: Fortran itself is a distinguished language with many meritorious implementations. It can be costly, though, finding the implementation you want/need for any specific environment. Gfortran, which supports Fortran 95 and a little of Fortran 2003, is part of GCC and is thus widely available. Binaries for g95, also based on GCC, are available for more than a dozen platforms, including Windows, Mac OS X, and Linux. I use both and consider only g95 mature, but gfortran does produce faster programs. Intel's Fortran compilers cost about $500 on Windows and Mac OS and $700 on Linux. It's not free, but I would not call it costly for professional developers. Speaking of money, gfortran and g95 have free manuals, the latter available in six languages http://ftp.g95.org/ . Final drafts of Fortran standards, identical to the official ISO standards, are freely available. The manual for Numpy costs $40 per copy. Sun also provides its sun studio ide and compilers(c , c++ and fortran) free of charge on x86 linux just have to register for free. http://developers.sun.com/sunstudio/downloads/ Alex -- http://mail.python.org/mailman/listinfo/python-list
Re: Fortran vs Python - Newbie Question
I feel obligated to fan the flames a bit by pointing to http://www.fortranstatement.com/ a site which advocates discontinuing development of Fortran and does a good job of summarizing the problems with the contemporary development of that language. I am not convinced that a new high performance language (Chapel, Fortress, etc.) is necessary. Rather, I feel that FORTRAN 77 is a mature tool, and that it, in combination with a powerful dynamic language (Python being my choice) is entirely sufficient for any foreseeable scientific computing. Fortran 90 and successors (F9* in the following) provide a baroque and elaborate effort to bolt modern computing methods over a finely honed special purpose tool (F77) that manages large numerical arrays spectacularly well. It is as if you decided to add a web search engine (an elaborate, developing set of requirements) to grep (a finely honed special purpose tool). It makes much more sense to add greplike features to your websearch tool than to try to foist Grep95 (competing with the Google search engine) on everyone who ever needs to find a misplaced text file. F77 interfaces smoothly and neatly with Python. F9* continues to be the single most difficult case for interoperability with any other contemporary algorithmic language. Fortunately there is hope within the new standard, where an interoperability flag will force F2003 to deliver arrays that are exportable. In exchange for this balkiness, F9* offers crude and verbose implementations of encapsulation and inheritance. I am sure Dr Beliavsky and some others are productive with F9*, but I would strongly advocate against it for anyone in a position to make a choice in the matter. Some people are competent with hand-powered drills, but I wouldn't set up a furniture production line with them on that basis. The performance and library advantages of Fortran are all available in F77. Higher level abstractions can easily be wrapped around the low level structures using Python and f2py. Making the combination performance-efficient requires some skill, but making a pure Fortran implementation efficient does no less so. I don't think we should or can abandon the excellent infrastructure provided by the Fortran of a generation ago. However, I am totally unconvinced that there is a point to a backward compatible extension to F77 that tries to support OOP and other abstractions unimaginable in the early days of Fortran. F77 and its numerical libraries are mature and complete. I think we should treat it as a remarkable set of packages, and move on. For any purposes I know of not involving an existing F9* legacy, I believe that Python plus F77 is as good as or superior to F9* alone. This includes the total time needed to learn the tools, (I think it is easier to learn Python, F77 and f2py than to learn F9* alone to any comparable skill level.) total time needed to develop the code, whole system performance, testability and maintainability. Once Python gets a first-class array type things will be even smoother as I understand it. mt -- http://mail.python.org/mailman/listinfo/python-list
Re: Fortran vs Python - Newbie Question
Tim Roberts [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] | Well, I'm being a bit argumentative here, but it's hard to deny that the | use of compiled in the context of .pyc (or .javac) is very different from | the use of compiled in the context of running gcc. Besides the fact that the object code does not corresponded to the public interface of any *current* processor, the compilation process is quite similar. Linear source code is parsed using standard techniques to produce a syntax tree. The tree is walked to produce object code in a different language. A certain amount of optimization is done. For instance, CPython compiles a 'while ' statement to a conditional jump past the end before the body and an absolute jump to the begining at the end. I am quite sure that gcc does essentially the same thing. If CPython (by 2.4, at least) recognizes the condition as a constant whose Bool value is True, it removes (optimizes away) the loading of the constant and the conditional jump that would never happen. Again, this is the same as gcc will do, I am sure, with at least some flag settings. | Once upon a time, | Basic enthusiasts would have used the word tokenized to describe .pyc files. Perhaps, but they would, I think, have been wrong. Tokenized Basic to the best of my knowledge, is a reversibly compressed version of the source file. The 'while' keyword, is there is one, is replaced by a number, but no parsing is done. Terry Jan Reedy -- http://mail.python.org/mailman/listinfo/python-list
Re: Fortran vs Python - Newbie Question
Terry Reedy wrote: Tim Roberts [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] | Once upon a time, | Basic enthusiasts would have used the word tokenized to describe .pyc files. Perhaps, but they would, I think, have been wrong. Tokenized Basic to the best of my knowledge, is a reversibly compressed version of the source file. The 'while' keyword, is there is one, is replaced by a number, but no parsing is done. Almost reversibly. The giveaway was when you listed your BASIC program and all the keywords came out upper-case, regardless of what case you'd typed them in. Mel. -- http://mail.python.org/mailman/listinfo/python-list
Re: Fortran vs Python - Newbie Question
In article [EMAIL PROTECTED], Beliavsky [EMAIL PROTECTED] wrote: . . . Your experience with Fortran is dated -- see below. I'll be more clear: Fortran itself is a distinguished language with many meritorious implementations. It can be costly, though, finding the implementation you want/need for any specific environment. Gfortran, which supports Fortran 95 and a little of Fortran 2003, is part of GCC and is thus widely available. Binaries for g95, also based on GCC, are available for more than a dozen platforms, including Windows, Mac OS X, and Linux. I use both and consider only g95 mature, but gfortran does produce faster programs. Intel's Fortran compilers cost about $500 on Windows and Mac OS and $700 on Linux. It's not free, but I would not call it costly for professional developers. Speaking of money, gfortran and g95 have free manuals, the latter available in six languages http://ftp.g95.org/ . Final drafts of Fortran standards, identical to the official ISO standards, are freely available. The manual for Numpy costs $40 per copy. My experience with Fortran is indeed dated. However, I still work with university groups that balk at $500 for valuable software--sometimes because of admini- strative conflicts with licensing (example: the group needs an educational license that fits its team perfectly, but educational license have to be approved by a campus-wide office that involves the group in expenses uncovered by its grants, and ... complications ensue). Intel's compiler, for example, is a great deal, and recognized as a trivial expense sometimes--but judged utterly impossible by a research group down a different corridor. My summary: practical success depends on specific details, and specific details in the Fortran and Python worlds differ. Also, Beliavsky, thanks for your report on the pertinent Fortran compilers. There *are* other proprietary Fortan compilers extant; do you expect them to fade away, leaving only g* and Intel, or are you simply remarking on those two as the (intellectual) market leaders? -- http://mail.python.org/mailman/listinfo/python-list
Re: Fortran vs Python - Newbie Question
On Mar 26, 12:59 pm, Erik Johnson [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] OK... I've been told that Both Fortran and Python are easy to read, and are quite useful in creating scientific apps for the number crunching, but then Python is a tad slower than Fortran because of its a high level language nature, so what are the advantages of using Python for creating number crunching apps over Fortran?? Thanks Chris So, after reading much of animated debate here, I think few would suggest that Python is going to be faster than FORTRAN when it comes to raw execution speed. Numeric and SciPy are Python modules that are geared towards numerical computing and can give substantial performance gians over plain Python. A reasonable approach (which has already been hinted at here), is to try to have the best of both world by mixing Python and FORTRAN - doing most of the logic and support code in Python and writing the raw computing routines in FORTRAN. A reasonable approach might be to simply make your application work in Python, then use profiling to identify what parts are slowest and move those parts into a complied language such as FORTRAN or C if overall performance is not fast enough. Unless your number crunching project is truly massive, you may find that Python is a lot faster than you thought and may be plenty fast enough on it's own. So, there is a tradeoff of resources between development time, execution time, readability, understandability, maintainability, etc. psyco is a module I haven't seen mentioned here - I don't know a lot about it, but have seen substantial increases in performance in what little I have used it. My understanding is that it produces multiple versions of functions tuned to particular data types, thus gaining some advantage over the default, untyped bytecode Python would normally produce. You can think of it as a JIT compiler for Python (but that's not quite what it is doing). The home page for that module is here: http://psyco.sourceforge.net/ Hope that help, -ej The question as originally framed was a little ignorant, of course. Python and Fortran are by no means subtitutes. Python is interpreted, comprehensively interroperates with just about anything, and is relatively slow. Fortran is compiled, interoperates with almost nothing and is blindingly fast. So it is like a battle between an elephant and a whale. If there is possible substitution, and hence competition, it is between Python+Numpy/Scipy on the one hand and Python+Fortran, via F2PY, on the other. My personal taste is to do things in Fortran when I can. It is really pretty simple to write well-structured, clear code in Fortran 95, and I don't find it troublesome to compile before I run. I don't find type declarations to be a nuisance; on the contrary, I think they're very useful for good documentation. Also I am somewhat mistrustful of Numpy/Scipy, because when I visit their forums, almost all the chatter is about bugs and/or failure of some function to work on some operating system. Perhaps I am wrong, but Python+Numpy/Scipy looks a little unstable. I understand that the purpose of Numpy/Scipy is to make it possible to do large-scale numerical computation in Python (practically all serious numerical computation these days is large-scale) without paying too much of a penalty in speed (relative to doing the same thing with a compiled language), but I have not yet been persuaded to take the trouble to learn the special programming vocabulary, essential tricks, and so forth, necessar for Numpy/Scipy when Fortran is ready to hand, very well established, and definitely faster. I do value Python very much for what it was designed for, and I do plan eventually to hook some of my Fortran code to Python via F2PY, so that interoperability with spreadsheets, OLAP and the like on the front and back ends of my information flow. Maybe somebody reading this will be able to convince me to look again at Numpy/Scipy, but for the time being I will continue to do my serious numerical computation in Fortran. -- http://mail.python.org/mailman/listinfo/python-list
Re: Fortran vs Python - Newbie Question
Mark Morss wrote: Maybe somebody reading this will be able to convince me to look again at Numpy/Scipy, but for the time being I will continue to do my serious numerical computation in Fortran. What I am missing in this discussion is a link to Pyrex to speed up Python: Pyrex is almost Python with the speed of compiled C. http://www.cosc.canterbury.ac.nz/greg.ewing/python/Pyrex/ Pyrex is adapted in SAGE (Software for Algebra and Geometry Experimentation) as Sagex: http://modular.math.washington.edu/sage/ Jaap -- http://mail.python.org/mailman/listinfo/python-list
Re: Fortran vs Python - Newbie Question
On Mar 27, 12:55 pm, Jaap Spies [EMAIL PROTECTED] wrote: Mark Morss wrote: Maybe somebody reading this will be able to convince me to look again at Numpy/Scipy, but for the time being I will continue to do my serious numerical computation in Fortran. What I am missing in this discussion is a link to Pyrex to speed up Python: Pyrex is almost Python with the speed of compiled C.http://www.cosc.canterbury.ac.nz/greg.ewing/python/Pyrex/ Pyrex is adapted in SAGE (Software for Algebra and Geometry Experimentation) as Sagex:http://modular.math.washington.edu/sage/ Jaap Well, the discussion was about Python vs. Fortran, and Pyrex, as I understand it, is a tool for linking C to Python. So I am not sure of the relevance of Pyrex to this particular discussion. F2PY is the leading tool for linking Fortran to Python, and I did mention that. -- http://mail.python.org/mailman/listinfo/python-list
Re: Fortran vs Python - Newbie Question
Steven D'Aprano [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Sheesh. Do Java developers go around telling everybody that Java is an interpreted language? I don't think so. What do you think the c in .pyc files stands for? Cheese? On the contrary... Sun is very careful to make sure you understand that Java is *COMPILED*! Remember, remember, always remember: Java is COMPILED! See that: the java compiler: javac. You have to call it explicitly when you build your Java software so that it compiles Java source code (that way Java executes really fast)!! (And don't forget, Java source is *compiled*, just like C++.) What's a JVM? Why would you need one since Java is *compiled*, remember? But seriously... I'm not a language or architecture guru. Is there any real difference between a JVM and an interpreter? I mean, I have some general feel that bytecode is a lower-level, more direct and more efficient thing to be interpreting that Java or Python source, but at the bottom level, you are still running an interpreter which is going to be (significantly?) more inefficient than executing native machine instructions directly on the CPU, right? Why is Python able to automatically compile source into bytecode on the fly (when needed) but Java still forces you to do so explicitly? I don't mean to bash Java - I think it has it's place as well, but I mean to note that Java is very carefully marketed whereas Python's image is not managed by a major, international corporation. -- http://mail.python.org/mailman/listinfo/python-list
Re: Fortran vs Python - Newbie Question
In [EMAIL PROTECTED], Mark Morss wrote: Well, the discussion was about Python vs. Fortran, and Pyrex, as I understand it, is a tool for linking C to Python. I think it's more than that. It's more a subset of Python with a little static typing. Ciao, Marc 'BlackJack' Rintsch -- http://mail.python.org/mailman/listinfo/python-list
Re: Fortran vs Python - Newbie Question
On Mar 27, 6:32 am, [EMAIL PROTECTED] (Cameron Laird) wrote: In article [EMAIL PROTECTED],Beliavsky [EMAIL PROTECTED] wrote: . . . Your experience with Fortran is dated -- see below. I'll be more clear: Fortran itself is a distinguished language with many meritorious implementations. It can be costly, though, finding the implementation you want/need for any specific environment. Gfortran, which supports Fortran 95 and a little of Fortran 2003, is part of GCC and is thus widely available. Binaries for g95, also based on GCC, are available for more than a dozen platforms, including Windows, Mac OS X, and Linux. I use both and consider only g95 mature, but gfortran does produce faster programs. Intel's Fortran compilers cost about $500 on Windows and Mac OS and $700 on Linux. It's not free, but I would not call it costly for professional developers. Speaking of money, gfortran and g95 have free manuals, the latter available in six languages http://ftp.g95.org/. Final drafts of Fortran standards, identical to the official ISO standards, are freely available. The manual for Numpy costs $40 per copy. My experience with Fortran is indeed dated. However, I still work with university groups that balk at $500 for valuable software--sometimes because of admini- strative conflicts with licensing (example: the group needs an educational license that fits its team perfectly, but educational license have to be approved by a campus-wide office that involves the group in expenses uncovered by its grants, and ... complications ensue). Intel's compiler, for example, is a great deal, and recognized as a trivial expense sometimes--but judged utterly impossible by a research group down a different corridor. My summary: practical success depends on specific details, and specific details in the Fortran and Python worlds differ. Also, Beliavsky, thanks for your report on the pertinent Fortran compilers. There *are* other proprietary Fortan compilers extant; do you expect them to fade away, leaving only g* and Intel, or are you simply remarking on those two as the (intellectual) market leaders? My point was that a few years ago an advantage of Python+Numeric or Octave or R over Fortran is that the former let one work at a much higher level, if one restricted oneself to using only free tools. The creation of g95 and gfortran has changed that somewhat, and the existence of commercial compilers is a plus, since they can surpass the free compilers in performance (Intel), functionality (creating Windows GUI programs entirely in Fortran, for example) or diagnosing errors (NAG, Lahey/Fujitsu and Salford/Silverfrost). A research group could purchase a single license of a commercial compiler to use in nightly builds but use the free compilers for development. Which commercial compilers will fade away? Decent free compilers will hurt the market for mediocre commercial ones, which may explain the demise of the compiler from NA Software. The Fortran 2003 standard adds many new features to Fortran 95, thus making big demands on vendors, and I have heard that Lahey and Salford will not be upgrading their compilers to the new standard. The active vendors appear to be Absoft, IBM, Intel, Pathscale, Portland, and Sun. -- http://mail.python.org/mailman/listinfo/python-list
Re: Fortran vs Python - Newbie Question
On Tue, 27 Mar 2007 12:11:01 -0600, Erik Johnson wrote:
But seriously... I'm not a language or architecture guru. Is there any
real difference between a JVM and an interpreter? I mean, I have some
general feel that bytecode is a lower-level, more direct and more efficient
thing to be interpreting that Java or Python source, but at the bottom
level, you are still running an interpreter which is going to be
(significantly?) more inefficient than executing native machine instructions
directly on the CPU, right?
Thirty (or more?) years ago, the differences between compilers and
interpreters was fairly large. Interpreters would scan the source code of
each and every line. If you had a loop, each line in the loop would be
parsed each time around the loop. Despite 30+ years of progress, that's
still the model that many (most?) people have in their head when they
think of interpreted language. That's why interpreted is the Kiss of
Death to anyone interested in speed -- whether true or not.
def if_(): # interpreted function
exec 'x = 0'
exec for i in range(100):
exec 'x += i'
return x
def cf(): # compiled function
x = 0
for i in range(100):
x += i
return x
timeit.Timer('cf()', 'from __main__ import cf').repeat(3, 1000)
[0.054703950881958008, 0.038740158081054688, 0.041306018829345703]
timeit.Timer('if_()', 'from __main__ import if_').repeat(3, 1000)
[16.228797912597656, 16.261317014694214, 15.885524034500122]
But these days, and probably for the last decade at least, the nice neat
lines between compiled and interpreted is much fuzzier. So-called
interpreted languages don't parse the source code every time it is run.
They compile to byte-code, which is interpreted in a virtual machine in
the same way that compiled code is interpreted in a real machine.
Even that distinction isn't necessarily cut and dried. On modern CPUs,
machine code itself can be implemented in a mini-language, which naturally
is interpreted by an interpreter built into the CPU. The real machine on
the CPU is likely to itself include virtual machines, up to and
including entire emulators of other CPUs.
(Note: for each and every generalization I have made, there are almost
certainly exceptions. I think that just supports my contention that the
generalizations about compiled and interpreted languages are more
misleading than useful.)
Why is Python able to automatically compile source into bytecode on the
fly (when needed) but Java still forces you to do so explicitly?
That probably has more to do with different programming models than
different technologies. I'm sure somebody could build an interactive
complier/interpreter for Java like Python's. If nobody has, it is probably
more to do with nobody seeing the need of such than because it can't be
done.
I suspect that the advantages of an interactive system are much less for
languages like Java that have static type declarations.
I don't mean to bash Java - I think it has it's place as well, but I
mean to note that Java is very carefully marketed whereas Python's image is
not managed by a major, international corporation.
Exactly. And that's why I think it does Python no favours at all to
keep emphasising the interpreter over the compiler. It gives too many
people the wrong idea.
--
Steven D'Aprano
--
http://mail.python.org/mailman/listinfo/python-list
Fortran vs Python - Newbie Question
OK... I've been told that Both Fortran and Python are easy to read, and are quite useful in creating scientific apps for the number crunching, but then Python is a tad slower than Fortran because of its a high level language nature, so what are the advantages of using Python for creating number crunching apps over Fortran?? Thanks Chris -- http://mail.python.org/mailman/listinfo/python-list
Re: Fortran vs Python - Newbie Question
On 26 Mar 2007 06:20:32 -0700, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: OK... I've been told that Both Fortran and Python are easy to read, and are Python is hugely easier to read. quite useful in creating scientific apps for the number crunching, but then Python is a tad slower than Fortran because of its a high level Fortran is massively faster than Python. language nature, so what are the advantages of using Python for creating number crunching apps over Fortran?? You can get the speed of fortran in Python by using libraries like Numeric without losing the readability of Python. Jean-Paul -- http://mail.python.org/mailman/listinfo/python-list
Re: Fortran vs Python - Newbie Question
On Mar 26, 8:20 am, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: OK... I've been told that Both Fortran and Python are easy to read, and are quite useful in creating scientific apps for the number crunching, but then Python is a tad slower than Fortran because of its a high level language nature, so what are the advantages of using Python for creating number crunching apps over Fortran?? Thanks Chris While I have never personally dealt with Fortran, I looked it up here: http://en.wikipedia.org/wiki/Fortran_code_examples The code examples speak for themselves. I recommend you look those over and then look over similar simple program written in Python. Python is still easier to read. Fortran also appears to be a compiled language, whereas Python is an interpreted language. Thus, Python programs can be tested faster. Fortran programs will likely run faster though. Check out www.python.org for good examples of Python code for the beginner and the advanced programmer. Mike -- http://mail.python.org/mailman/listinfo/python-list
Re: Fortran vs Python - Newbie Question
On Mar 26, 9:20 am, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: OK... I've been told that Both Fortran and Python are easy to read, and are quite useful in creating scientific apps for the number crunching, but then Python is a tad slower than Fortran because of its a high level language nature, so what are the advantages of using Python for creating number crunching apps over Fortran?? Thanks Chris The standard way is to perform the number crunching in Fortran and to use Python as glue. See for instance the scipy project, which includes the f2py bridge. Michele Simionato -- http://mail.python.org/mailman/listinfo/python-list
Re: Fortran vs Python - Newbie Question
On Mar 26, 3:20 pm, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: OK... I've been told that Both Fortran and Python are easy to read, and are quite useful in creating scientific apps for the number crunching, but then Python is a tad slower than Fortran because of its a high level language nature, so what are the advantages of using Python for creating number crunching apps over Fortran?? Portability, scalability RAD. -- http://mail.python.org/mailman/listinfo/python-list
Re: Fortran vs Python - Newbie Question
On Mar 26, 2:42 pm, Jean-Paul Calderone [EMAIL PROTECTED] wrote: On 26 Mar 2007 06:20:32 -0700, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: OK... I've been told that Both Fortran and Python are easy to read, and are Python is hugely easier to read. quite useful in creating scientific apps for the number crunching, but then Python is a tad slower than Fortran because of its a high level Fortran is massively faster than Python. language nature, so what are the advantages of using Python for creating number crunching apps over Fortran?? You can get the speed of fortran in Python by using libraries like Numeric without losing the readability of Python. Can you back this up with some source?? Chris -- http://mail.python.org/mailman/listinfo/python-list
Re: Fortran vs Python - Newbie Question
On 26 Mar 2007 06:47:18 -0700, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: On Mar 26, 2:42 pm, Jean-Paul Calderone [EMAIL PROTECTED] wrote: On 26 Mar 2007 06:20:32 -0700, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: OK... I've been told that Both Fortran and Python are easy to read, and are Python is hugely easier to read. quite useful in creating scientific apps for the number crunching, but then Python is a tad slower than Fortran because of its a high level Fortran is massively faster than Python. language nature, so what are the advantages of using Python for creating number crunching apps over Fortran?? You can get the speed of fortran in Python by using libraries like Numeric without losing the readability of Python. Can you back this up with some source?? Half the code in Numeric was compiled from fortran. Need I go on? :) Jean-Paul -- http://mail.python.org/mailman/listinfo/python-list
Re: Fortran vs Python - Newbie Question
You can get the speed of fortran in Python by using libraries like Numeric without losing the readability of Python. Can you back this up with some source?? Chris Is this really the most important issue in your choice ? As said by others, Portability, scalability RAD as an advantage of Python are probably far more important. And on the other hand Python is perfect as glue between Fortran and whatsoever. To emphasize that, I expect the number of lines in Python is at least 3 times less than in Fortran. I did some comparison between MatLab and Python (Scipy) for real-time analysis, and for all my cases Pyhton van 3 .. 7 times faster than MatLab. So I'ld suggest to start with downloading the Enthought edition of Python, and you can judge for yourself within 10 minutes, if it's fast enough. cheers, Stef Mientki -- http://mail.python.org/mailman/listinfo/python-list
Re: Fortran vs Python - Newbie Question
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 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. As Fortran programs have historically been authored and hacked on by successive generations of grad students, this is the most vital feature of all. 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. 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. Python is a tad slower than Fortran If the Fortran program turns out to have been broken all along, then who cares? -- http://mail.python.org/mailman/listinfo/python-list
Re: Fortran vs Python - Newbie Question
On 26 Mar, 15:06, stef [EMAIL PROTECTED] wrote: You can get the speed of fortran in Python by using libraries like Numeric without losing the readability of Python. Can you back this up with some source?? Chris Is this really the most important issue in your choice ? As said by others, Portability, scalability RAD as an advantage of Python are probably far more important. And on the other hand Python is perfect as glue between Fortran and whatsoever. To emphasize that, I expect the number of lines in Python is at least 3 times less than in Fortran. I did some comparison between MatLab and Python (Scipy) for real-time analysis, and for all my cases Pyhton van 3 .. 7 times faster than MatLab. So I'ld suggest to start with downloading the Enthought edition of Python, and you can judge for yourself within 10 minutes, if it's fast enough. cheers, Stef Mientki Is there a mac version?? Thanks Chris -- http://mail.python.org/mailman/listinfo/python-list
Re: Fortran vs Python - Newbie Question
On Mar 26, 4:47 pm, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: You can get the speed of fortran in Python by using libraries like Numeric without losing the readability of Python. Can you back this up with some source?? Chris If you execute one command in Python which tells a super-optimized Fortran-routine to do lots of work, the overhead of Python will be neglible. That's all there is to it, no need for a source. -- http://mail.python.org/mailman/listinfo/python-list
Re: Fortran vs Python - Newbie Question
[EMAIL PROTECTED] [EMAIL PROTECTED] wrote: ... So I'ld suggest to start with downloading the Enthought edition of Python, and you can judge for yourself within 10 minutes, if it's fast enough. cheers, Stef Mientki Is there a mac version?? http://download.enthought.com/MacEnthon/ReadMe.html but it's self labeled as 0.1 Test Release i.e. somewhat preliminary; it claims to support only Panther (10.3) and its 2.3.0 Python (no claims for Tiger, 10.4, and its 2.3.5 Python, nor for other Python Mac istalls yet). If you're just trying to learn and check things out, it might be better to get a more recent Python from python.org (2.5 or 2.4.4) and the various other packages as and when you need them (you can use the MacEnthon list as a guide:-). You'll need a C compiler to be sure you can install any package from sources -- Apple's XCode includes gcc, it's free, and it's the safest choice (but it's a HUGE download, as it comes with a lot of stuff -- I don't think Apple offers a simple way to install just gcc and minimal supporting tools). Alex -- http://mail.python.org/mailman/listinfo/python-list
Re: Fortran vs Python - Newbie Question
In article [EMAIL PROTECTED], Jean-Paul Calderone [EMAIL PROTECTED] wrote: On 26 Mar 2007 06:20:32 -0700, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: OK... I've been told that Both Fortran and Python are easy to read, and are Python is hugely easier to read. quite useful in creating scientific apps for the number crunching, but then Python is a tad slower than Fortran because of its a high level Fortran is massively faster than Python. language nature, so what are the advantages of using Python for creating number crunching apps over Fortran?? You can get the speed of fortran in Python by using libraries like Numeric without losing the readability of Python. Jean-Paul Me, too. A lot of language questions are correctly answered, Indistinguishable, to within the range of subjective response. This is NOT the case for the readability and performance of Fortran and Python, though; the differences are as massive as Jean-Paul says. HOWEVER, that's all true only in general. As a new- comer to both Fortran and Python, there's a fair chance that the Fortran code you first produce would be so suboptimal as to perform no better than the corresponding Python. My vote, therefore, is this: unless you're in an organization that provides a lot of Fortran support to such beginners as yourself, choose Python. It has all the pertinent advantages. We can discuss secondary concerns at more length, if you wish: Python's better suited than Fortran for a range of other applications you might wish to tackle some day; Python originated from a language- for-beginners project, and truly is something you can start to pick up in a day; your own scientific specialty might be one that's particularly well- endowed with an existing body of code written in Fortran (or Python, or C++, or ...); and so on. -- http://mail.python.org/mailman/listinfo/python-list
Re: Fortran vs Python - Newbie Question
On 26 Mar 2007 06:20:32 -0700, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: OK... I've been told that Both Fortran and Python are easy to read, and are quite useful in creating scientific apps for the number crunching, but then Python is a tad slower than Fortran because of its a high level language nature, so what are the advantages of using Python for creating number crunching apps over Fortran?? Thanks Chris Dear Chris, Why are you focusing on Python vs. Fortran? There might be other choices out there you might want to consider, specifically C, O'Caml, and Ada, since you mention number crunching. When choosing, you should consider what other requirements you'll have; some people have hinted at a few, such as portability (I am not saying fortrain ain't portable) and rapid application development. Will you be doing lots of string manipulation? Processing text-files? Gluing applications? What do people around you use? What type of number crunching will you be doing? Are the libraries available in any of the languages that you are considering that do some/most of what you want to do? Are you concernded about concurrent/distributed programming? Is this your first programming language? Etc, etc, etc. In the end, maybe neither Python nor Fortran might be the best choices for you. HTH, R. -- http://mail.python.org/mailman/listinfo/python-list -- Ramon Diaz-Uriarte Statistical Computing Team Structural Biology and Biocomputing Programme Spanish National Cancer Centre (CNIO) http://ligarto.org/rdiaz -- http://mail.python.org/mailman/listinfo/python-list
Re: Fortran vs Python - Newbie Question
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
Re: Fortran vs Python - Newbie Question
On Mar 26, 3:20 pm, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: I've been told that Both Fortran and Python are easy to read, and are quite useful in creating scientific apps for the number crunching, but then Python is a tad slower than Fortran because of its a high level language nature, so what are the advantages of using Python for creating number crunching apps over Fortran?? Fortran may be faster, but Python (with NumPy and SciPy) is often fast enough. A lot of practitioners use Matlab, which is often slower than Python. Matplotlib is an excellent Python extension for graphing data. Anyone serious about numerical computing should learn Fortran 95. But use it sparsely and only where its needed. Fortran is perfect for numerical work but useless for anything else. Usually the amount of code that will benefit from using Fortran over NumPy makes up less than a percent of the line count. You can call Fortran from Python using f2py, so you can get the best from both worlds. -- http://mail.python.org/mailman/listinfo/python-list
Re: Fortran vs Python - Newbie Question
[EMAIL PROTECTED] a écrit : On Mar 26, 8:20 am, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: OK... I've been told that Both Fortran and Python are easy to read, and are quite useful in creating scientific apps for the number crunching, but then Python is a tad slower than Fortran because of its a high level language nature, so what are the advantages of using Python for creating number crunching apps over Fortran?? Thanks Chris While I have never personally dealt with Fortran, I looked it up here: http://en.wikipedia.org/wiki/Fortran_code_examples The code examples speak for themselves. I recommend you look those over and then look over similar simple program written in Python. Python is still easier to read. Fortran also appears to be a compiled language, whereas Python is an interpreted language. Being 'compiled' or 'interpreted' is not a feature of a language, but of a given implementation of a language (and even then, some implementations of some languages supports both). wrt/ CPython (the reference implementation), it is actually compiled to byte-code - just like Java. The main difference being that the VM is smart enough to automagically (re)compile what's needed. -- http://mail.python.org/mailman/listinfo/python-list
Re: Fortran vs Python - Newbie Question
In article [EMAIL PROTECTED], [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: . . . You can get the speed of fortran in Python by using libraries like Numeric without losing the readability of Python. Can you back this up with some source?? Chris Yes. While evidence in computing science is ... well, the standards aren't well established; still, I think you'll want to start with URL: http://www.sciencemag.org/cgi/content/abstract/279/5356/1525 . This describes a supercomputer simulation that won awards in the '90s for its performance. The application itself is basically what Jean-Paul recommended: Python, with high-performance libraries written in C, C++, and Fortran. -- http://mail.python.org/mailman/listinfo/python-list
Re: Fortran vs Python - Newbie Question
In article [EMAIL PROTECTED], [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: . . . Is there a mac version?? Thanks Chris Yes. Several, in fact--all available at no charge. The Python world is different from what experience with Fortran might lead you to expect. I'll be more clear: Fortran itself is a distinguished language with many meritorious implementations. It can be costly, though, finding the implementation you want/need for any specific environment. Python, in contrast, is blessed with a plethora of implementations and variations, all of which are available without licensing fee. In particular, recent Mac OS X installations INCLUDE Python--it's already in there! -- http://mail.python.org/mailman/listinfo/python-list
Re: Fortran vs Python - Newbie Question
In article [EMAIL PROTECTED], Alex Martelli [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: ... So I'ld suggest to start with downloading the Enthought edition of Python, and you can judge for yourself within 10 minutes, if it's fast enough. cheers, Stef Mientki Is there a mac version?? http://download.enthought.com/MacEnthon/ReadMe.html but it's self labeled as 0.1 Test Release i.e. somewhat preliminary; it claims to support only Panther (10.3) and its 2.3.0 Python (no claims for Tiger, 10.4, and its 2.3.5 Python, nor for other Python Mac istalls yet). If you're just trying to learn and check things out, it might be better to get a more recent Python from python.org (2.5 or 2.4.4) and the various other packages as and when you need them (you can use the MacEnthon list as a guide:-). You'll need a C compiler to be sure you can install any package from sources -- Apple's XCode includes gcc, it's free, and it's the safest choice (but it's a HUGE download, as it comes with a lot of stuff -- I don't think Apple offers a simple way to install just gcc and minimal supporting tools). Alex Yes and no. Alex, while useful scientific computing under Mac OS X will almost certainly eventually involve installation of XCode and so on, Nomad.C can start to learn Python without a need to install ANYTHING. As you know, Python is already there, and the version that comes with 10.4 (2.3.5, as nearly as I can easily tell) is easily adequate to take him through the Tutorial (with minor exceptions). Also, while I, like you, am aware of no minimal-gcc package from Apple, I think third parties make it available. However, I'm not motivated enough at this point to track down the details. I think Nomad.C should start with what he has under 10.4, and plan to move on later to all of XCode. -- http://mail.python.org/mailman/listinfo/python-list
Re: Fortran vs Python - Newbie Question
Alex Martelli wrote: [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: ... So I'ld suggest to start with downloading the Enthought edition of Python, and you can judge for yourself within 10 minutes, if it's fast enough. cheers, Stef Mientki Is there a mac version?? http://download.enthought.com/MacEnthon/ReadMe.html but it's self labeled as 0.1 Test Release i.e. somewhat preliminary; it claims to support only Panther (10.3) and its 2.3.0 Python (no claims for Tiger, 10.4, and its 2.3.5 Python, nor for other Python Mac istalls yet). It no longer exists, in fact. I don't know why the readme still exists, too. If you're just trying to learn and check things out, it might be better to get a more recent Python from python.org (2.5 or 2.4.4) and the various other packages as and when you need them (you can use the MacEnthon list as a guide:-). You'll need a C compiler to be sure you can install any package from sources -- Apple's XCode includes gcc, it's free, and it's the safest choice (but it's a HUGE download, as it comes with a lot of stuff -- I don't think Apple offers a simple way to install just gcc and minimal supporting tools). Here are some more instructions for building the usual suspects: numpy, scipy, VTK, PIL, ipython, matplotlib. https://svn.enthought.com/enthought/wiki/IntelMacPython25 -- Robert Kern I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth. -- Umberto Eco -- http://mail.python.org/mailman/listinfo/python-list
Re: Fortran vs Python - Newbie Question
On Mar 26, 9:42 am, Jean-Paul Calderone [EMAIL PROTECTED] wrote: On 26 Mar 2007 06:20:32 -0700, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: OK... I've been told that Both Fortran and Python are easy to read, and are Python is hugely easier to read. quite useful in creating scientific apps for the number crunching, but then Python is a tad slower than Fortran because of its a high level Fortran is massively faster than Python. language nature, so what are the advantages of using Python for creating number crunching apps over Fortran?? You can get the speed of fortran in Python by using libraries like Numeric without losing the readability of Python. This is true only for problems that can take advantage of scalability, which is a large and important subset of all numerical problems, but is still only a subset. Some problems (e.g., simulation) require repeated sequential evaluation of formulas. For other problems (e.g., collision detection) the operands change rapidly. The scalability of numpy doesn't help so much here. (Anecdote: I once did a collision detection using Numeric. It would take slices out of the data set as it narrowed down the possible collisions. It actually worked pretty well. But the slicing was crazy and hard to follow. I rewrote it in C and it was both faster and more readable.) Carl Banks -- http://mail.python.org/mailman/listinfo/python-list
Re: Fortran vs Python - Newbie Question
[EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] OK... I've been told that Both Fortran and Python are easy to read, and are quite useful in creating scientific apps for the number crunching, but then Python is a tad slower than Fortran because of its a high level language nature, so what are the advantages of using Python for creating number crunching apps over Fortran?? Thanks Chris So, after reading much of animated debate here, I think few would suggest that Python is going to be faster than FORTRAN when it comes to raw execution speed. Numeric and SciPy are Python modules that are geared towards numerical computing and can give substantial performance gians over plain Python. A reasonable approach (which has already been hinted at here), is to try to have the best of both world by mixing Python and FORTRAN - doing most of the logic and support code in Python and writing the raw computing routines in FORTRAN. A reasonable approach might be to simply make your application work in Python, then use profiling to identify what parts are slowest and move those parts into a complied language such as FORTRAN or C if overall performance is not fast enough. Unless your number crunching project is truly massive, you may find that Python is a lot faster than you thought and may be plenty fast enough on it's own. So, there is a tradeoff of resources between development time, execution time, readability, understandability, maintainability, etc. psyco is a module I haven't seen mentioned here - I don't know a lot about it, but have seen substantial increases in performance in what little I have used it. My understanding is that it produces multiple versions of functions tuned to particular data types, thus gaining some advantage over the default, untyped bytecode Python would normally produce. You can think of it as a JIT compiler for Python (but that's not quite what it is doing). The home page for that module is here: http://psyco.sourceforge.net/ Hope that help, -ej -- http://mail.python.org/mailman/listinfo/python-list
Re: Fortran vs Python - Newbie Question
On 26 Mar, 17:59, Erik Johnson [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] OK... I've been told that Both Fortran and Python are easy to read, and are quite useful in creating scientific apps for the number crunching, but then Python is a tad slower than Fortran because of its a high level language nature, so what are the advantages of using Python for creating number crunching apps over Fortran?? Thanks Chris So, after reading much of animated debate here, I think few would suggest that Python is going to be faster than FORTRAN when it comes to raw execution speed. Numeric and SciPy are Python modules that are geared towards numerical computing and can give substantial performance gians over plain Python. A reasonable approach (which has already been hinted at here), is to try to have the best of both world by mixing Python and FORTRAN - doing most of the logic and support code in Python and writing the raw computing routines in FORTRAN. A reasonable approach might be to simply make your application work in Python, then use profiling to identify what parts are slowest and move those parts into a complied language such as FORTRAN or C if overall performance is not fast enough. Unless your number crunching project is truly massive, you may find that Python is a lot faster than you thought and may be plenty fast enough on it's own. So, there is a tradeoff of resources between development time, execution time, readability, understandability, maintainability, etc. psyco is a module I haven't seen mentioned here - I don't know a lot about it, but have seen substantial increases in performance in what little I have used it. My understanding is that it produces multiple versions of functions tuned to particular data types, thus gaining some advantage over the default, untyped bytecode Python would normally produce. You can think of it as a JIT compiler for Python (but that's not quite what it is doing). The home page for that module is here: http://psyco.sourceforge.net/ Hope that help, -ej Ok Thanks you all for giving a little insight into what Python can actually do, I think I've read enough to convince me that Python is generally a very flexible, fast, powerful language that can be used in a wide variety of applications instead of focusing on numerical functions like fortran does. Thanks again! -- http://mail.python.org/mailman/listinfo/python-list
RE: Fortran vs Python - Newbie Question
1. Python is fun! 2. Python is cool! 3. Most of the time you can google a solution, i.e. somebody has already done nearly everything you can think of. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of [EMAIL PROTECTED] Sent: Monday, March 26, 2007 8:21 AM To: python-list@python.org Subject: Fortran vs Python - Newbie Question OK... I've been told that Both Fortran and Python are easy to read, and are quite useful in creating scientific apps for the number crunching, but then Python is a tad slower than Fortran because of its a high level language nature, so what are the advantages of using Python for creating number crunching apps over Fortran?? Thanks Chris -- http://mail.python.org/mailman/listinfo/python-list -- http://mail.python.org/mailman/listinfo/python-list
Re: Fortran vs Python - Newbie Question
On Mon, 26 Mar 2007 06:40:49 -0700, kyosohma wrote: Fortran also appears to be a compiled language, whereas Python is an interpreted language. Sheesh. Do Java developers go around telling everybody that Java is an interpreted language? I don't think so. What do you think the c in .pyc files stands for? Cheese? -- Steven. -- http://mail.python.org/mailman/listinfo/python-list
Re: Fortran vs Python - Newbie Question
On Mar 26, 3:20 pm, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: OK... I've been told that Both Fortran and Python are easy to read, and are quite useful in creating scientific apps for the number crunching, but then Python is a tad slower than Fortran because of its a high level language nature, so what are the advantages of using Python for creating number crunching apps over Fortran?? Thanks Chris Personally, my #1 reason for favoring Python is the interpreter. When developing code which implements complex algorithms/calculations, I always find I want to play around with things during development. Using Python's interpreter this is a real joy! Now, I don't mean tweaking the almost-finalized implementation - I mean tweaking bits and pieces of code during all stages of development. For instance: Optimizing an algorithm's parameters by trying different combinations out under different circumstances. Or checking the potential gains from pre-processing something. Or writing a specialized version of a certain function and testing it for correctness and performance. Etc, etc. As for my background - I have developed number-crunching software with C, C++ and Python over the past 5 years, and have recently learned Fortran as well. Python has consistently failed to disappoint me :) - Tal Einat reduce(lambda m,x:[m[i]+s[-1] for i,s in enumerate(sorted(m))], [[chr(154-ord(c)) for c in '.-,l.Z95193+179-']]*18)[3] -- http://mail.python.org/mailman/listinfo/python-list
Re: Fortran vs Python - Newbie Question
On Mar 26, 8:40 am, [EMAIL PROTECTED] wrote: On Mar 26, 8:20 am, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: OK... I've been told that Both Fortran and Python are easy to read, and are quite useful in creating scientific apps for the number crunching, but then Python is a tad slower than Fortran because of its a high level language nature, so what are the advantages of using Python for creating number crunching apps over Fortran?? Thanks Chris While I have never personally dealt withFortran, I looked it up here: http://en.wikipedia.org/wiki/Fortran_code_examples The code examples speak for themselves. I recommend you look those over and then look over similar simple program written in Python. Code written using the features of modern Fortran (90 or later), including free source form, looks better than code written in Fortran 66 or 77. Except that Fortran uses keywords to terminate blocks rather than indentation as in Python, properly indented Fortran does not look much different from Python. Neither language requires curly braces or semicolons to terminate blocks and lines. It does not make sense to argue against programming in Fortran 95 now because of limitations that were removed long ago. -- http://mail.python.org/mailman/listinfo/python-list
Re: Fortran vs Python - Newbie Question
On Mar 26, 7:13 pm, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Thanks you all for giving a little insight into what Python can actually do, I think I've read enough to convince me that Python is generally a very flexible, fast, powerful language that can be used in a wide variety of applications instead of focusing on numerical functions like fortran does. I wouldn't go as far as to say Python is a 'fast' language. But it's certainly fun (particularly that), powerful, readable, and useful, even for numerical computing. Speed in numerical computing is a strange beast. First, a small bottleneck in your code is likely to dominate the execution time. But very often it is impossible to guess where it is, common sense usually doesn't help, for some strange reason. You can use the Python profiler to identify the real bottlenecks, but you may be surprised when you find where they are. These bottlenecks are the only portion of the code that can benefit from being moved to Fortran or C. The bottlenecks will dominate regardless of what you do to the rest of you code. You may gain nothing from moving the bottlenecks to C or Fortran. Don't let that surprise you. Python may be doing the work as fast as it can be done. It may actually be the case that moving this code to C or Fortran causes a slowdown. Python may be calling hand tuned C, assembly or Fortran code that you cannot match. You can hand code a sorting routine in C, but will you be able to beat Python's 'timsort'? Probably not! Timsort is one of the fastest and stable sorting routines known to man. It has taken years to develop and fine tune, and you simply cannot beat that, even if you spend hours on end optimizing your code. The same holds for the hashing routines in Pythons dictionaries. You can write a hashtable in C, but I doubt it can match the speed of Python's dictionaries. And then there is files, strings, network sockets and protocols, access to databases, encryption, etc. Python's libraries are tuned by people who knew what they were doing and had the time to do the fiddling. Most likely you don't (well, I certainly do not). Finally, you will most likely use numerical libraries like LAPACK and BLAS. These are written in Fortran or C anyway. Whether you call the libraries from Fortran or Python may not matter very much! In the end, the code that can really benefit from being moved to C or Fortran is rare to come by. Python is a very high-level language. That means there are certain things that put constraint on the attained speed. Most importantly: keep the number of interpreter evals as scarce as possible. If you make a for loop, the interpreter may evaluate the lines within the loop several times. Languages like C, C++ and Java really teach you bad habits when it comes to an interpreted language like Python. In these languages, loops are almost free. In Python, they may be very expensive as the interpreter is invoked multiple times. But if you can 'vectorize' the loop statement into a one-liner (or a few lines) using slicing, list comprehensions or functional programming (e.g. the lambda, map and filter intrinsics), the overhead will be very small. That is the secret to getting high-performance from a language like Python. If you can get away from the C++ habit of using for loops for any kind of iteration, Python may not feel sluggish at all. In the end, the main determinant of performance in numerical tasks is really big-O, not the language you prefer to use. Choice of algorithm is fare more important than the Python vs. Fortran issue! -- http://mail.python.org/mailman/listinfo/python-list
Re: Fortran vs Python - Newbie Question
On Mar 26, 8:42 am, Jean-Paul Calderone [EMAIL PROTECTED] wrote: snip You can get the speed of fortran in Python by using libraries like Numeric without losing the readability of Python. Numeric and Numpy will faster than raw Python for array operations, but I don't think they will match well-written C or Fortran, because compilers can better optimize code in those less dynamic languages. Someone recently mentioned here (Quantum term project code- for interest and for help) an example where Numeric was 180 times faster in Fortran 95 using gfortran, asking for advice on how to speed up the Python code -- see https://wiki.asu.edu/phy416/index.php/A_Simple_Bose-Einstein_Condensate_Simulation . No one replied. -- http://mail.python.org/mailman/listinfo/python-list
Re: Fortran vs Python - Newbie Question
On Mon, 26 Mar 2007 15:53:56 -0700, sturlamolden wrote: Python is a very high-level language. That means there are certain things that put constraint on the attained speed. Most importantly: keep the number of interpreter evals as scarce as possible. If you make a for loop, the interpreter may evaluate the lines within the loop several times. Languages like C, C++ and Java really teach you bad habits when it comes to an interpreted language like Python. In these languages, loops are almost free. In Python, they may be very expensive as the interpreter is invoked multiple times. Jeez-Louise, this is why my blood boils when I read ignora^H^H^H^H misguided people referring to Python as interpreted: it leads other people to imagine that Python is interpreting lines over and over and over again. Is the interpreter invoked multiple times in a for loop? Let's find out. Here is a function with a for loop: def looper(): x = 1 for i in range(100): print x x += i return x Let's look at the compiled code: dis.dis(looper) 2 0 LOAD_CONST 1 (1) 3 STORE_FAST 0 (x) 3 6 SETUP_LOOP 35 (to 44) 9 LOAD_GLOBAL 0 (range) 12 LOAD_CONST 2 (100) 15 CALL_FUNCTION1 18 GET_ITER 19 FOR_ITER21 (to 43) 22 STORE_FAST 1 (i) 4 25 LOAD_FAST0 (x) 28 PRINT_ITEM 29 PRINT_NEWLINE 5 30 LOAD_FAST0 (x) 33 LOAD_FAST1 (i) 36 INPLACE_ADD 37 STORE_FAST 0 (x) 40 JUMP_ABSOLUTE 19 43 POP_BLOCK 644 LOAD_FAST0 (x) 47 RETURN_VALUE Certainly Python isn't interpreting the lines in the for loop one million times. It interprets them once, compiles them once, and executes them one million times. But if you can 'vectorize' the loop statement into a one-liner (or a few lines) using slicing, list comprehensions or functional programming (e.g. the lambda, map and filter intrinsics), the overhead will be very small. This is generally good advice because it moves the loop from moderately fast Python code to very fast C code, not because Python is interpreting each line over and over again. -- Steven. -- http://mail.python.org/mailman/listinfo/python-list
Re: Fortran vs Python - Newbie Question
On Mar 26, 9:06 am, stef [EMAIL PROTECTED] wrote: As said by others, Portability, scalability RAD as an advantage of Python are probably far more important. All of those claimed advantages can be debated, although they may exist for some tasks. (1) Portability. Fortran has been run on hundreds if not thousands of platforms since 1957. People who value portability often want assurance that their code will be supported by compilers/interpreters produced in the future. Standard-conforming Fortran 95 code is conforming Fortran 2003 code, and the standards committee has decided not to remove features in future versions. Python 3 is still somewhat up in the air, and it will NOT be backward compatible with Python 2.x, although migration tools will be provided. (2) Scalability. If talking about parallel computing, the widely used OpenMP Application Program Interface (API) supports multi-platform shared-memory parallel programming only in C/C++ and Fortran. In general, high performance computing is done in C, C++, and Fortran. (3) RAD. Scripting programs WILL be faster to write in Python, because of duck typing, the many built-in data structures, and other features. For larger programs, a Fortran (or C++ or Java) compiler will catch some errors at compile time that are caught only at run time in Python, perhaps after considerable time has elapsed. Furthermore, the higher speed of Fortran may mean that the time between program runs is 1 minute vs. 10 minutes in the corresponding Python program. This can speed the development cycle. -- http://mail.python.org/mailman/listinfo/python-list
Re: Fortran vs Python - Newbie Question
On Mar 26, 10:31 am, Carl Banks [EMAIL PROTECTED] wrote: snip 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. I quite agree with you. People have written big, mission-critical programs to run nuclear reactors and design planes in Fortran 66 and 77, although I hoped that they ran static analysis programs such as FTNCHEK to verify them. Fortran 90 and later versions has modules, whose use allows the compiler to check types in procedure calls. I used Fortran 77 in my physics PhD program and find that I am much more productive in Fortran 95 now, making fewer errors not caught at compile time. The operations on arrays and array sections in Fortran 90+ help one to write number-crunching code that is clear as glass. -- http://mail.python.org/mailman/listinfo/python-list
Re: Fortran vs Python - Newbie Question
On Mar 26, 10:16 am, [EMAIL PROTECTED] (Cameron Laird) wrote: In article [EMAIL PROTECTED],[EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Is there a mac version?? Thanks Chris Yes. Several, in fact--all available at no charge. The Python world is different from what experience with Fortran might lead you to expect. Your experience with Fortran is dated -- see below. I'll be more clear: Fortran itself is a distinguished language with many meritorious implementations. It can be costly, though, finding the implementation you want/need for any specific environment. Gfortran, which supports Fortran 95 and a little of Fortran 2003, is part of GCC and is thus widely available. Binaries for g95, also based on GCC, are available for more than a dozen platforms, including Windows, Mac OS X, and Linux. I use both and consider only g95 mature, but gfortran does produce faster programs. Intel's Fortran compilers cost about $500 on Windows and Mac OS and $700 on Linux. It's not free, but I would not call it costly for professional developers. Speaking of money, gfortran and g95 have free manuals, the latter available in six languages http://ftp.g95.org/ . Final drafts of Fortran standards, identical to the official ISO standards, are freely available. The manual for Numpy costs $40 per copy. -- http://mail.python.org/mailman/listinfo/python-list
Re: Fortran vs Python - Newbie Question
Cameron Laird [EMAIL PROTECTED] wrote: ... If you're just trying to learn and check things out, it might be better to get a more recent Python from python.org (2.5 or 2.4.4) and the various other packages as and when you need them (you can use the MacEnthon list as a guide:-). You'll need a C compiler to be sure you can install any package from sources -- Apple's XCode includes gcc, it's free, and it's the safest choice (but it's a HUGE download, as it comes with a lot of stuff -- I don't think Apple offers a simple way to install just gcc and minimal supporting tools). Yes and no. Alex, while useful scientific computing under Mac OS X will almost certainly eventually involve installation of XCode and so on, Nomad.C can start to learn Python without a need to install ANYTHING. As you know, Python is already there, and the version that comes with 10.4 (2.3.5, as nearly as I can easily tell) is easily adequate to take him through the Tutorial (with minor exceptions). I disagree: the Python 2.3.5 distributed by Apple as part of MacOSX 10.4 comes _without_ readline -- meaning that an up-arrow at the interactive interpreter prompt gives Esc-[-A, a left-arrow gives Esc-[-D, etc, instead of usefully recovering previous lines and allowing easy edit of the current line. There is really no reason one should suffer through that! python.org's 2.5 DMG (and, if I recall correctly, 2.4.4 as well) come with a working idle, which is even nicer to use, and at any rate a working readline, so that one can easily correct minor mistakes made entering code at the interactive interpreter. XCode, or other add-ons, may surely come later, but downloading the 2.5 or 2.4.4 DMG from python.org is HIGHLY recommended anyway. Also, while I, like you, am aware of no minimal-gcc package from Apple, I think third parties make it available. However, I'm not motivated enough at this point to track down the details. I think Nomad.C should start with what he has under 10.4, and plan to move on later to all of XCode. 10.4 does come with a version of XCode (on MacOSX's DVD, if not already on disk in /Applications/Installers) -- though not the latest and greatest, it's quite likely to be adequate for any learning whatsoever. The bundled Python is a different issue, and I do _not_ consider it adequate -- I'd suggest 2.5 instead, though 2.4.4 will be fine too. Alex -- http://mail.python.org/mailman/listinfo/python-list
Re: Fortran vs Python - Newbie Question
[EMAIL PROTECTED] [EMAIL PROTECTED] wrote: I've been told that Both Fortran and Python are easy to read, and are quite useful in creating scientific apps for the number crunching, but Incidentally, and a bit outside what you asked: if your number crunching involves anything beyond linear systems, run, don't walk, to get Forman Acton's Real Computing Made Real, http://www.amazon.com/Real-Computing-Made-Engineering-Calculations/dp/0 486442217/ref=ed_oe_p/002-1610918-5308009 -- the original hardback was a great buy at $50, and now you can have the Dover paperback at $12.44 -- a _steal_, I tell you! You don't need any programming background (and there's no code in the book): you need good college-level maths, which is all the book uses (in abundance). It doesn't teach you the stuff you can easily find on the web, such as, say, Newton's method for the numerical solution of general equations: it teaches you to _understand_ the problems you're solving, the foibles of numerical computation, how to massage and better condition your equations not to run into those foibles, when to apply the classic methods (those you can easily find on the web) and to what versions of your problems _and why_, etc, etc. It may be best followed with a cheap calculator (and lots of graph paper, a pencil, and a good eraser:-), though Python+matplotlib will be OK and Fortran+some equivalent plotting library should be fine too. Let me just give you my favorite, _simplest_ example... say we want to find the two values of x that solve the quadratic: a x**2 + b x + c x = 0 Looks like a primary/middle school problem, right? We all know: x = ( -b +/- sqrt(b**2 - 4 a c) ) / 2 a so we verify that b**2 4 a c (to have two real solutions), take the square root, then do the sum and the difference of the square root with - b, and divide by 2 a. Simple and flawless, right?! Whoa, says Acton! What if 4 a c is much smaller than b**2? Then that sqrt will be very close to b -- and inevitably, depending on the sign of b, either the sum or the difference will be a difference between two numbers that are VERY close to each other. Such operations are the foremost poison of numeric computation! When you take the difference between numbers that are very close, you're dropping significant digits all over the place: one of your roots will be well computed, the other one may well be a disaster. Solution: take EITHER the sum OR the difference -- specifically, the one that is actually a sum, not a difference, depending on the sign of b. That gives you one root with good precision. Then, exploit the fact that the product of the roots is c/a - compute the other root by dividing this constant by the root you've just computed, and the precision will be just as good for the other root, too. Sure, this is a trick you expect to be already coded in any mathematical library, in the function that solves quadratics for you -- exactly because it's so simple and so general. But the key point is, far too many people doing number crunching ignore even such elementary issues -- and too many such issues are far too idiosyncratic to specific equations, quadratures, etc, to be built into any mathematical library you may happen to be using. Acton's book should be mandatory reading for anybody who'll ever need to crunch numbers...!-) (I've taught Numerical Analysis to undergrad level engineers, and while I know I've NOT done anywhere as good a job as Acton does, even forearming my students with 1/4th of the techniques so well covered in the book, did, in my opinion, make them better computors, to borrow Acton's term, than any of their peers... _I_ was never thought any of this precious, indispensable stuff in college, I had to pick it all up later, in the school of hard knocks!-). Alex -- http://mail.python.org/mailman/listinfo/python-list
Re: Fortran vs Python - Newbie Question
Carl Banks wrote: 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. Hear hear. Python and Fortran both have their place. I'm a grad student in Electromagnetics (radio frequency research) and I depend a lot on number crunching to help me design the latest and greatest rader array to the coolest cell phone that will connect anywhere. I actually use python to speed up my development of codes for Fortran. I prototype some function that I want in python and then use the final draft of it in my fortran code. What used to take several hours I can do in less than one by leveraging both languages for what they're good for, Python for RAD and Fortran for fast number crunching of my research. Chris -- http://mail.python.org/mailman/listinfo/python-list
