[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.

alex

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