[SciPy-user] numarray interface and performance issues (for dot product and transpose)

A.Schmolck a.schmolck at gmx.net
Fri Mar 1 10:38:26 CST 2002

Travis Oliphant <oliphant at ee.byu.edu> writes:
> [eric writes:]
> > should go fast.  The NumPy guys *might* go for requireing ATLAS, but I find that
> > highly unlikely because it is such a bear to build on some platforms and takes
> > so long on all platforms.  One of the beauties of NumPy is that it is self
> > contained.
> >
> > SciPy has already bitten the bullet as far as considering ATLAS as part of the
> > core requirements, so it comes as no extra effort.  We should just add the ATLAS
> > code patch to SciPy's linalg module and then import those functions into the
> > main namespace.
> >
> I agree.  I would much rather do this then change Numeric.

I perfectly agree that Numeric shouldn't _require_ atlas (especially if it
hopes to find its way into python core) and I should have clarified this point
in my email. However, I can't see what's wrong with _optionally_ using atlas,
if the user so desires. That's what #ifdef's are for :)

Indeed, richard's modifications to multiarraymodule.c are neatly wrapped in a
couple of #ifdef DOTBLAS statements.

Wouldn't such a solution introduce less maintenance work than scipy
maintaining its own, atlas/blas-enabled only, version of Numeric? Personally,
I'm happy if the patch only makes it into scipy, since I already use scipy
anyway, but I guess having and (optional) speedup > factor 40 can't hurt
Numeric either (if it doesn't involve too much maintenance work) and will
surely make some of its users happy.


Alexander Schmolck     Postgraduate Research Student
                       Department of Computer Science
                       University of Exeter
A.Schmolck at gmx.net     http://www.dcs.ex.ac.uk/people/aschmolc/

More information about the SciPy-user mailing list