Fortran vs Python - Newbie Question

[Nomad.C]

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

 

[kyosohma]

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

 

[Michele Simionato]

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

 

[Bart Ogryczak]

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.

 

[Nomad.C]

Python is hugely easier to read.


Fortran is massively faster than Python.





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

 

[stef]

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

 

[Andy Dingley]

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?

 

[Nomad.C]

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

 

[irstas]

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.

 

[Alex Martelli]

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

 

[Cameron Laird]

.
.
.

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.

 

[Cameron Laird]

.
.
.

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!

 

[Cameron Laird]

<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.

 

[Carl Banks]

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?

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

 

[Ramon Diaz-Uriarte]

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.






--
Ramon Diaz-Uriarte
Statistical Computing Team
Structural Biology and Biocomputing Programme
Spanish National Cancer Centre (CNIO)
http://ligarto.org/rdiaz

 

[sturlamolden]

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.

 

[Carl Banks]

Python is hugely easier to read.


Fortran is massively faster than Python.


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

 

[Bruno Desthuilliers]

(e-mail address removed) a écrit :

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.

 

[Robert Kern]

<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

 

[Erik Johnson]

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