[Numpy-discussion] .debs of numpy-0.9.8 available for Ubuntu Dapper

[Arnd Baecker]

On Thu, 8 Jun 2006, Andrew Straw wrote:

> Arnd Baecker wrote:
> > What worries me is
> > a) the Build conflicts: atlas3-base
> >
> I hoped to investigate further and post afterwards, but my preliminary
> findings that led to this decision are:
>
> 1) building with atlas (atlas3-base and atlas3-base-dev) caused a
> significant slowdown (~10x) on my simple test on amd64 arch:
>
> import timeit
> shape = '(40,40)'
> timeit.Timer('a=ones(shape=%s);svd(a)'%shape,'from numpy import ones;
> from numpy.linalg import svd')
> print "NumPy: ", t2.repeat(5,500)
>
> 2) Even having atlas installed (atlas3-base on amd64) caused a
> significant slowdown (~2x) on that test. This was similar to the case
> for i386, where I installed atlas3-sse2.
> 3) This is done in the source packages by Matthias Klose for both
> numeric and numarray, too. I figured he knows what he's doing.

Alright, this ATLAS stuff always puzzled me and I thought that one
has to have atlas3-base and atlas3-base-dev atlas3-headers
installed to use atlas3 during compilation.
I assumed that installing additionally (even afterwards)
atlas3-sse2 should give
optimal performance on the corresponding machine.
(Thinking about this, it is not clear why then atlas3-sse2-dev,
so the previous statement must be wrong ...)

OTOH, `apt-cache rdepends atlas3-base` shows a pretty long list,
including python2.3-scipy, python2.3-numeric-ext, python2.3-numarray-ext

OK, obviously I haven't understood the ATLAS setup of debian
and better shut up now and leave this for the experts .... ;-)

Tomorrow I will remove the atlas3-base stuff before building and
see how things work
(I don't need that urgently as building from source seems
easier, but the benefit of having proper debian packages
pays off very quickly in the longer run ...)

> > b) and the python2.3-dev *and* python2.4-dev dependency
> >
> This is a _build_ dependency. The source package builds python
> python2.3-numpy and python2.4-numpy, so it needs Python.h for both.

Alright, so no problem here - thanks for the clarification.

[...]

> > What about scipy: presently debian sarge comes with
> > scipy 0.3.2. Installing old-scipy and new-scipy side-by side
> > seems impossible (unless one does something like wxversion select
> > stuff...) - should the new scipy debs just replace the old ones?
> >
> Unless you do some apt-pinning, I think any new scipy (0.4.x) in any
> repository in your sources list will automatically override the old
> (0.3.x) simply via the versioning mechanisms of apt-get. I like the idea
> of a wxversion-alike, but I've shifted all my code to use numpy and the
> new scipy, so I don't have any motivation to do any implementation.

Also, it might not be completely trivial to set up and
there is still a lot of other stuff which has to be done ...

Best, Arnd