[Numpy-discussion] Fortran was dead ... [was Re: rewriting NumPy code in C or C++ or similar]
Mon Mar 14 17:02:32 CDT 2011
On Mon, Mar 14, 2011 at 9:24 PM, Ondrej Certik <email@example.com> wrote:
> Hi Sturla,
> On Tue, Mar 8, 2011 at 6:25 AM, Sturla Molden <firstname.lastname@example.org> 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);
>> 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.
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
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 !? ;-)
More information about the NumPy-Discussion