I've been reading the posts on this topic with considerable interest. For a moment, I want to emphasize the "code-cleanup" angle more literally than the functionality mods suggested so far. Several months ago, I hacked my personal copy of the NumPy distribution so that I could use the Intel Math Kernel Library for Windows. The IMKL is (1) freely available from Intel at http://developer.intel.com/vtune/perflibst/mkl/index.htm; (2) basically BLAS and LAPACK, with an FFT or two thrown in for good measure; (3) optimized for the different x86 processors (e.g., generic x86, Pentium II & III); (4) configured to use 1, 2, or 4 processors; and (5) configured to use multithreading. It is an impressive, fast implementation. I'm sure there are similar native libraries available on other platforms. Probably due to my inexperience with both Python and NumPy, it took me a couple of days to successfully tear out the f2c'd stuff and get the IMKL linking correctly. The parts I've used work fine, but there are probably other features that I haven't tested yet that still aren't up to snuff. In any case, the resulting code wasn't very pretty. As long as the NumPy code is going to be commented and cleaned up, I'd be glad to help make sure that the process of using a native BLAS/LAPACK distribution (which was probably compiled using Fortran storage and naming conventions) is more straightforward. Among the more tedious issues to consider are: (1) The extent of the support for LAPACK. Do we want to stick with LAPACK Lite? (2) The storage format. If we've still got row-ordered matrices under the hood, and we want to use native LAPACK libraries that were compiled using column-major format, then we'll have to be careful to set all of the flags correctly. This isn't going to be a big deal, _unless_ NumPy will support more of LAPACK when a native library is available. Then, of course, there are the special cases: the IMKL has both a C and a Fortran interface to the BLAS. (3) Through the judicious use of header files with compiler-dependent flags, we could accommodate the various naming conventions used when the FORTRAN libraries were compiled (e.g., sgetrf_ or SGETRF). The primary output of this effort would be an expansion of the "Compilation Notes" subsection of Section 15 of the NumPy documentation, and some header files that made the recompilation easier than it is now. Regards, Ray ============================ Ray Beausoleil Hewlett-Packard Laboratories mailto:beausol@hpl.hp.com Vox: 425-883-6648 Fax: 425-883-2535 HP Telnet: 957-4951 ============================