[Matrix-SIG] An Experiment in code-cleanup.

[Beausoleil, Raymond]

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
============================