[Numpy-discussion] Proposed Roadmap Overview

[Paul Anton Letnes]

On 20. feb. 2012, at 16:29, Sturla Molden wrote:

> Den 20.02.2012 08:35, skrev Paul Anton Letnes:
>> 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:
> 
> Yes ... but it does not make Fortran a systems programming language. 
> Making NumPy is different from using it.
> 
>> - 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)
> 
> That is nice for numerical computing, but not really needed to make NumPy.
> 
> 
>> - arrays that mentally map very well onto numpy arrays. To me, this spells +1 to ease of contribution, over some abstract C/C++ template
> 
> Mentally perhaps, but not binary. NumPy needs uniformly strided memory 
> on the binary level. Fortran just gives this at the mental level. E.g. 
> there is nothing that dictates a Fortran pointer has to be a view, the 
> compiler is free to employ copy-in copy-out. In Fortran, a function call 
> can invalidate a pointer.  One would therefore have to store the array 
> in an array of integer*1, and use the intrinsic function transfer() to 
> parse the contents into NumPy dtypes.
> 
>> - in newer standards it has some nontrivial mathematical functions: gamma, bessel, etc. that numpy lacks right now
> 
> That belongs to SciPy.

I don't see exactly why. Why should numpy have exponential but not gamma functions? The division seems kinda arbitrary. Not that I am arguing violently for bessel functions in numpy.

>> - compilers that are good at optimizing for floating-point performance, because that's what Fortran is all about
> 
> Insanely good, but not when we start to do the (binary, not mentally) 
> strided access that NumPy needs. (Not that C compilers would be any better.)
> 
> 
> 
>> - 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.
> 
> Not f2py, as it depends on NumPy.
> 
> - some programmers know Fortran better than C++. Fortran is at least used by many science guys, like me.
> 
> 
> That is a valid arguments. Fortran is also much easier to read and debug.
> 
> 
> Sturla

Thanks for an excellent answer, Sturla - very informative indeed.

Paul.