[Numpy-discussion] Fortran was dead ... [was Re: rewriting NumPy code in C or C++ or similar]

Tue Mar 15 05:27:46 EDT 2011

On Mon, 14 Mar 2011 23:10:13 +0100, Matthieu Brucher <matthieu.brucher at gmail.com> wrote:
> Hi,
> 
> Intel Fortran is an excellent Fortran compiler. Why is Fortran still better
> than C and C++?
> - some rules are different, like arrays passed to functions are ALWAYS
> supposed to be independent in Fortran, whereas in C, you have to add a
> restrict keyword
> - due to the last fact, Fortran is a language where its compiler could do
> more work (vectorization, autoparallelization...)
> - Fortran 95 has an excellent array support, which is not currently
> available in C/C++ (perhaps with ArBB?)
> 
> Nevertheless, when you know C++ correctly, when you want to do something
> really efficient, you don't use Fortran. You can be as efficient as in C++,
> and you can do fancy stuff (I/O, network...). Class and templates are also
> better supported in C++.
bah...
usually, a scientist doesn't want to do fancy stuff.
fancy stuff gets in the way at the end of the day.
what a scientist wants is to do number crunching as efficiently as
possible w/o having to learn about all the traps that a language can lay
for the unwarry.

gfortran has received less attention than its fellow C and C++ friends
lately (or so I hear) but it supports almost all of Fortran-2003 and
bits and pieces of Fortran-2008:
 http://gcc.gnu.org/wiki/Fortran2003
 http://gcc.gnu.org/wiki/Fortran2003Status
 http://gcc.gnu.org/wiki/Fortran2008Status

not having to rely on a computing farm to build large scale software is
really something nice when you come back from C++ and templates.
my only problems with Fortran are the indexing (not 0-based, even if you
can declare arrays to start at index 0, it isn't common) and the non
C-order of arrays.
both of these worries are just stemming from habit rather than standing
on technical grounds, though.

-s

> 
> Matthieu
> 
> 2011/3/14 Sebastian Haase <seb.haase at gmail.com>
> 
> > On Mon, Mar 14, 2011 at 9:24 PM, Ondrej Certik <ondrej at certik.cz> wrote:
> > > Hi Sturla,
> > >
> > > On Tue, Mar 8, 2011 at 6:25 AM, Sturla Molden <sturla at molden.no> wrote:
> > >> Den 08.03.2011 05:05, skrev Dan Halbert:
> > >>> Thanks, that's a good suggestion. I have not written Fortran since
> > 1971,
> > >>> but it's come a long way. I was a little worried about the row-major vs
> > >>> column-major issue, but perhaps that can be handled just by remembering
> > >>> to reverse the subscript order between C and Fortran.
> > >>
> > >> In practice this is not a problem. Most numerical libraries for C assume
> > >> Fortran-ordering, even OpenGL assumes Fortran-ordering. People program
> > >> MEX files for Matlab in C all the time. Fortran-ordering is assumed in
> > >> MEX files too.
> > >>
> > >> In ANSI C, array bounds must be known at compile time, so a Fortran
> > >> routine with the interface
> > >>
> > >>     subroutine foobar( lda, A )
> > >>         integer lda
> > >>         double precision A(lda,*)
> > >>     end subroutine
> > >>
> > >> will usually be written like
> > >>
> > >>     void foobar( int lda, double A[]);
> > >>
> > >> in C, ignoring different calling convention for lda.
> > >>
> > >> Now we would index A(row,col) in Fortran and A[row + col*lda] in C. Is
> > >> that too difficult to remember?
> > >>
> > >> In ANSI C the issue actually only arises with small "array of arrays"
> > >> having static shape, or convoluted contructs like "pointer to an array
> > >> of pointers to arrays". Just avoid those and stay with 1D arrays in C --
> > >> do the 1D to 2D mapping in you mind.
> > >>
> > >> In C99 arrays are allowed to have dynamic size, which mean we can do
> > >>
> > >>    void foobar( int lda, double *pA )
> > >>    {
> > >>       typedef double row_t [lda];
> > >>       vector_t *A = (vector_t*)((void*)&pA[0]);
> > >>
> > >> Here we must index A[k][i] to match A(i,k) in Fortran. I still have not
> > >> seen anyone use C99 like this, so I think it is merely theoretical.
> > >>
> > >> Chances are if you know how to do this with C99, you also know how to
> > >> get the subscripts right. If you are afraid to forget "to reverse the
> > >> subscript order between C and Fortran", it just tells me you don't
> > >> really know what you are doing when using C, and should probably use
> > >> something else.
> > >>
> > >> Why not Cython? It has "native support" for NumPy arrays.
> > >>
> > >> Personally I prefer Fortran 95, but that is merely a matter of taste.
> > >
> > > +1 to all that you wrote about Fortran. I am pretty much switching to
> > > it from C/C++ for all my numerical work, and then I use Cython to call
> > > it from Python, as well as cmake for the build system.
> > >
> > > Ondrej
> >
> >
> > Hi,
> > this is quite amazing...
> > Sturla has been writing so much about Fortran recently, and Ondrej now
> > says he has done the move from C/C++ to Fortran -- I thought Fortran
> > was dead ... !?   ;-)
> > What am I missing here ?
> > Apparently (from what I was able to read-up so far) there is a BIG
> > difference between FORTRAN 77 and F95.
> > But isn't gcc or gfortran still only supporting F77 ?
> > How about IntelCC's Fortran ?  Is that superior?
> > Do you guys have any info / blogs / docs where one could get an
> > up-to-date picture?
> > Like:
> > 1. How about debugging - does gdb work or is there somthing better ?
> > 2. How is the move of the F77 community to F95 in general ?   How many
> > people / projects are switching.
> > 3. Or is the move rather going like Fortran 77 -> C -> Python ->
> > Fortran 95   !?  ;-)
> >
> > Thanks,
> > Sebastian Haase
> > _______________________________________________
> > NumPy-Discussion mailing list
> > NumPy-Discussion at scipy.org
> > http://mail.scipy.org/mailman/listinfo/numpy-discussion
> >
> 
> 
> 
> -- 
> Information System Engineer, Ph.D.
> Blog: http://matt.eifelle.com
> LinkedIn: http://www.linkedin.com/in/matthieubrucher
Non-text part: text/html
> _______________________________________________
> NumPy-Discussion mailing list
> NumPy-Discussion at scipy.org
> http://mail.scipy.org/mailman/listinfo/numpy-discussion

-- 
#########################################
# Dr. Sebastien Binet
# Laboratoire de l'Accelerateur Lineaire
# Universite Paris-Sud XI
# Batiment 200
# 91898 Orsay
#########################################
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20110315/26e4b747/attachment.sig>