Fortran vs Python - Newbie Question

[Mark Morss]

On Mar 26, 12:59 pm, "Erik Johnson" <nob... at invalid.com> wrote:
> <Noma... at gmail.com> wrote in message
>
> news:1174915232.414568.197250 at p15g2000hsd.googlegroups.com...
>
> > 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.