[chm]

I really like your project. I do question its usefulness however. If you get any performance hit from using these, you beat the point of using Fortran (over say Python) in the first place :) Don't you think?

[greglindahl]

This is a Show HN, please don't be negative. The comment you replied to addresses what you asked already!

[quantumhobbit]

There is certainly an advantage to being able to use a single language in your project instead of two separate languages.

[chm]

Yes, and having worked with Fortran code for years, we used the routines to calculate... and Python to analyze the data. A colleague even scrapped old Fortran routines in favor of Python + Numpy, as he could be more productive without a noticeable slowdown in his work, as the data analysis part was the bottleneck. So I reiterate my point: I like the project, I like the idea, but we need more information regarding the performance of the routines. Otherwise, using e.g. Python full-stack could be much less of a hassle.

[gaius]

NumPy is FORTRAN under the covers, e.g. BLAS IIRC.

[greglindahl]

BLAS are generally implemented in assembly these days, although they do have Fortran interfaces.

[gnufx]

The important kernels (particularly GEMM) are written in assembler, but you can see OpenBLAS, for instance, importing netlib LAPACK.

[defgeneric]

Did you miss the point the OP just made above? Performance-critical code paths can be left alone while the usual set-up/tear-down code can make good use of this library.

[GFK_of_xmaspast]

The gap between fortran and python is so huge that you can afford a performance hit on the fortran end and still end up way ahead.