[SciPy-dev] Linalg2 benchmarks

[pearu at scipy.org]

Hi Jochen,

On 7 Apr 2002, Jochen Küpper wrote:

> Well, knowing what Travis posted I must say what I find strange is t
> he compared Numeric's lapack_lite with ATLAS where it is so easy to
> use a machine optimized LAPACK/BLAS with Numeric.  And btw. ATLAS
> isn't always the best choice here -- one reason why I don't like this
> tight binding to ATLAS too much.

Using site.cfg it is possible to use your own lapack/blas
libraries in favour of atlas ones by specifying a proper order.
Though currently you still need atlas otherwise building cblas will fail.

In future, we can remove the strict dependence of linalg on ATLAS easily
as cblas or clapack routines are not used directly but through their
wrappers blas.py and lapack.py.

> something related: How much work would it be to get f2py/LinAlg to
> work with numarray?

Actually it should not be difficult. The most intensive use of Numeric
array C/API is in fortranobject.c, basically, in the function
array_from_pyobj and its dependencies. There is no need to change
signature files. That's the whole beauty of using tools like f2py for
generating extension modules automatically.

When numarray will have a stable and documented C/API interface, I'll look
for its support in f2py.

> There is a numpy_compat now that supports almost all of Numeric, so
> this would be one way.  But in the long run one would like to have a
> native implementation of linalg, of course...

I am not sure that numpy_compat will work straightforward for f2py as f2py
is quite aware of Numeric array internals. But on the other hand, I have
not looked what is done in numpy_compat or numarray lately.

Pearu