[Matrix-SIG] Lapack, fftpack, and ranlib becoming part of Multipack

[hinsen@dirac.cnrs-orleans.fr]

> I looked over the source to the lapack, fftpack, and ranlib modules
> and see that it will be quite simple to add them to the current
> Multipack distribution. In fact, they fit in quite nicely with the
> changes that Pearu has made.

Sorry for the late reply; I just discovered that my subscription
to the Matrix-SIG was deactivated for some reason unknown to me,
so I missed all of this month's traffic.

I agree that it makes sense to move the non-essential parts of NumPy
somewhere else, but there are also some compatibility considerations,
since many other packages already use these modules.

First of all, NumPy contains C versions of everything, whereas
Multipack uses the original Fortran versions. It is certainly better
to use the Fortran versions whereever possible, but it also makes
installation significantly more difficult (or even impossible, for
those who don't have a Fortran compiler). Installation problems are
already the single most frequent cause of questions I get about my
packages, and therefore I would definitely refuse to make any of my
published code dependent on other modules that require Fortran.

In fact, I'd prefer to see Multipack move towards a "Fortran if
possible, C if not" approach. Running the Fortran modules through f2c
is not much work. Then a (yet-to-be-written) installation script would
decide if it can use the Fortran version on a given machine, and if
not would use the C translations. The best of both worlds: maximum
performance and maximum portability.

Another problem is licenses. As I understand it, LGPL is more
restrictive than the Python/NumPy license, although I don't understand
the details. In fact, I don't understand at all what LGPL (as opposed
to GPL) means for Python code, which is not linked to anything! I'd
just like to make sure that licensing problems don't prevent
non-academic users from using the code.

Finally, a suggestion for Multipack: Instead of importing everything
into one top-level module, I'd prefer a package structure. In fact,
I'd prefer to have each "XXXpack" as one module within Numeric (that
doesn't require all the code to be distributed with NumPy, but it does
require some changes to the current NumPy distribution).

Konrad.
-- 
-------------------------------------------------------------------------------
Konrad Hinsen                            | E-Mail: hinsen@cnrs-orleans.fr
Centre de Biophysique Moleculaire (CNRS) | Tel.: +33-2.38.25.55.69
Rue Charles Sadron                       | Fax:  +33-2.38.63.15.17
45071 Orleans Cedex 2                    | Deutsch/Esperanto/English/
France                                   | Nederlands/Francais
-------------------------------------------------------------------------------