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. _______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion