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.
> 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.
> Clearly, python-setuptools and cdbs are not yet installed
> on my system (should be no problem).
>
I hope the setuptools issue, in particular, does not present a problem.
As I said, I have created this repository for work, and I find
setuptools to be invaluable for maintaining order amongst all the Python
packages I use internally. In any case, this is again only a build
dependency -- all it does is creates a numpy-0.9.8-py2.x.egg-info
directory in site-packages alongside numpy.
Let me be clear, since there's a lot of trepidation regarding
setuptools: there is no use of setuptools (or even installation of
setuptools) required to use these packages. Setuptools is required only
to build from source.
>> If I get some positive feedback, I'm likely to add this to the scipy.org
>> download page. Also, I hope the official Debian and Ubuntu distros pick
>> up numpy soon, and perhaps this will speed them along.
>>
>
> yes - that would be brilliant!
>
OK, I'll wait a couple of days for some positive confirmation that this
stuff works, (even from the various systems I'm setting up this
repository for), and then I'll post it on the website.
> 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.
_______________________________________________
Numpy-discussion mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/numpy-discussion
