[Numpy-discussion] Proposed Roadmap Overview

Paul Anton Letnes paul.anton.letnes at gmail.com
Mon Feb 20 02:35:46 EST 2012


In the language wars, I have one question. Why is Fortran not being considered? Fortran already implements many of the features that we want in NumPy:
- slicing and similar operations, at least some of the fancy indexing kind
- element-wise array operations and function calls
- array bounds-checking and other debugging aid (with debugging flags)
- arrays that mentally map very well onto numpy arrays. To me, this spells +1 to ease of contribution, over some abstract C/C++ template
- in newer standards it has some nontrivial mathematical functions: gamma, bessel, etc. that numpy lacks right now
- compilers that are good at optimizing for floating-point performance, because that's what Fortran is all about
- not Fortran as such, but BLAS and LAPACK are easily accessed by Fortran
- possibly other numerical libraries that can be helpful
- Fortran has, in its newer standards, thought of C interoperability. We could still keep bits of the code in C (or even C++?) if we'd like to, or perhaps f2py/Cython could do the wrapping.
- some programmers know Fortran better than C++. Fortran is at least used by many science guys, like me. Until someone comes along with actual numbers or at least anecdotal evidence, I don't think the "more programmers know X than Y" argument is too interesting. Personally I've learned both, and Fortran is much more accessible than C++ (to me) if you're used to the "work with (numpy) arrays" mentality.

As far as I can understand, implementing element-wise operations, slicing, and a host of other NumPy features is in some sense pointless - the Fortran compiler authors have already done it for us. Of course some nice wrapping will be needed in C, Cython, f2py, or similar. Since my understanding is limited, I'd be interested in being proved wrong, though :)

Paul




More information about the NumPy-Discussion mailing list