Bug#489726: should numpy be built with atlas?

2008-07-08 Thread Matthias Klose
[EMAIL PROTECTED] writes:
 On Mon, Jul 7, 2008 at 2:12 PM, Matthias Klose [EMAIL PROTECTED] wrote:
  Package: python-numpy
  Version: 1:1.1.0-2
  Severity: serious
 
  python-numpy now has an unconditional dependency on libatlas3gf-base,
  needing the specialized atlas libraries as a runtime
  dependency. Users still should have the option to use the standard
  blas and lapack libs instead of the untested/unmaintained atlas
  libraries in debian.
 
 The problem is that the new (1.0) numpy building system needs ATLAS 
 at compile time to enable fast matrix-multiplication. If ATLAS is not found
 at compile time, numpy.core._dotblas.so is not built and slow matrix 
 multiplication is used even if the end user has ATLAS installed. In the old
 numpy _dotblas.so was always compiled using refblas and the end user 
 would still have had the option of using ATLAS. I'm not sure I understand 
 why ATLAS is now needed at compile time, but look here:
 http://scipy.org/scipy/numpy/ticket/667
 and here:
 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=464784
 
 I think python-numpy should stay as it is now and a bug-wishlist should be 
 reported to the atlas package to encourage packaging of the new stable
  version (3.8.2). Filing a ticket on numpy trac may help, but the fate of 
 ticket 667 seems to indicate that there's no will of fixing this bug 
 upstream...

thanks for the update. Looking at the blas package, I see that the
cblas library is included in libblas3.  So it looks like the numpy
check is wrong, testing for a package name, and not for a
feature. This seems to explain why it did work in etch, and this
should be fixed in python-numpy.

  Matthias



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Bug#489726: should numpy be built with atlas?

2008-07-08 Thread Tiziano Zito
On 7/8/08, Matthias Klose [EMAIL PROTECTED] wrote:
  thanks for the update. Looking at the blas package, I see that the
  cblas library is included in libblas3.  So it looks like the numpy
  check is wrong, testing for a package name, and not for a
  feature. This seems to explain why it did work in etch, and this
  should be fixed in python-numpy.

Hi Ondrej, Hi Matthias. Removing the two lines in numpy/core/setup.py indeed
seems to do the trick. Feel free to test the attached patch, generated
against the python-numpy source package in sid. On my system it
generates a numpy package with a _dotblas.so file correctly linked to
lapack libs. If ATLAS is then installed, the ATLAS libraries are used
instead.
Ondrej: if the patch works, would you report it upstream?

have a nice day!
tiziano


atlas.patch
Description: Binary data


Bug#489726: should numpy be built with atlas?

2008-07-08 Thread Ondrej Certik
On Tue, Jul 8, 2008 at 1:58 PM, Tiziano Zito [EMAIL PROTECTED] wrote:
 On 7/8/08, Matthias Klose [EMAIL PROTECTED] wrote:
  thanks for the update. Looking at the blas package, I see that the
  cblas library is included in libblas3.  So it looks like the numpy
  check is wrong, testing for a package name, and not for a
  feature. This seems to explain why it did work in etch, and this
  should be fixed in python-numpy.

 Hi Ondrej, Hi Matthias. Removing the two lines in numpy/core/setup.py indeed
 seems to do the trick. Feel free to test the attached patch, generated
 against the python-numpy source package in sid. On my system it
 generates a numpy package with a _dotblas.so file correctly linked to
 lapack libs. If ATLAS is then installed, the ATLAS libraries are used
 instead.
 Ondrej: if the patch works, would you report it upstream?

Yes, but first I'll upload a new package, because depending on the
atlas packages is not good.

It works on my system. Your script (attached) gives me:

$ ./test_atlas.py
Using ATLAS:
0.53141283989
$ wajig remove atlas3-base libatlas3gf-base
$ ./test_atlas.py
Using ATLAS:
1.64572000504

So it seems to work, even though the difference is not so big.

I am now going to test the package on i386 and then upload if all is
ok. We can then talk with upstream what is the best way to fix this in
the long term.

Ondrej
#! /usr/bin/env python
import numpy
import time

try:
   import numpy.core._dotblas
   print 'Using ATLAS:'
except ImportError:
   print 'No ATLAS:'

t = time.time()
x = numpy.random.random((1000,1000))
y = numpy.random.random((1000,1000))
z = numpy.dot(x, y)

print time.time()-t


Bug#489726: should numpy be built with atlas?

2008-07-07 Thread Ondrej Certik
On Mon, Jul 7, 2008 at 2:12 PM, Matthias Klose [EMAIL PROTECTED] wrote:
 Package: python-numpy
 Version: 1:1.1.0-2
 Severity: serious

 python-numpy now has an unconditional dependency on libatlas3gf-base,
 needing the specialized atlas libraries as a runtime
 dependency. Users still should have the option to use the standard
 blas and lapack libs instead of the untested/unmaintained atlas
 libraries in debian.

Hi Matthias,

I changed that on a request from a user:

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=489253

so should we revert this change? I.e. should numpy not be built with
atlas support? This will make it quite slow in Debian.

CCing to debian python as well to get more opinions on this.

Thanks,
Ondrej



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Bug#489726: should numpy be built with atlas?

2008-07-07 Thread Matthias Klose
Ondrej Certik writes:
 On Mon, Jul 7, 2008 at 2:12 PM, Matthias Klose [EMAIL PROTECTED] wrote:
  Package: python-numpy
  Version: 1:1.1.0-2
  Severity: serious
 
  python-numpy now has an unconditional dependency on libatlas3gf-base,
  needing the specialized atlas libraries as a runtime
  dependency. Users still should have the option to use the standard
  blas and lapack libs instead of the untested/unmaintained atlas
  libraries in debian.
 
 Hi Matthias,
 
 I changed that on a request from a user:
 
 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=489253
 
 so should we revert this change? I.e. should numpy not be built with
 atlas support? This will make it quite slow in Debian.
 
 CCing to debian python as well to get more opinions on this.

afaiu this has nothing to do if blas/lapack or atlas are used;
apparently _dotblas.so is not built when just using blas/lapack. this
seems to be the real bug which we should fix.

  Matthias



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Bug#489726: should numpy be built with atlas?

2008-07-07 Thread [EMAIL PROTECTED]
On Mon, Jul 7, 2008 at 2:12 PM, Matthias Klose [EMAIL PROTECTED] wrote:
 Package: python-numpy
 Version: 1:1.1.0-2
 Severity: serious

 python-numpy now has an unconditional dependency on libatlas3gf-base,
 needing the specialized atlas libraries as a runtime
 dependency. Users still should have the option to use the standard
 blas and lapack libs instead of the untested/unmaintained atlas
 libraries in debian.

The problem is that the new (1.0) numpy building system needs ATLAS 
at compile time to enable fast matrix-multiplication. If ATLAS is not found
at compile time, numpy.core._dotblas.so is not built and slow matrix 
multiplication is used even if the end user has ATLAS installed. In the old
numpy _dotblas.so was always compiled using refblas and the end user 
would still have had the option of using ATLAS. I'm not sure I understand 
why ATLAS is now needed at compile time, but look here:
http://scipy.org/scipy/numpy/ticket/667
and here:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=464784

I think python-numpy should stay as it is now and a bug-wishlist should be 
reported to the atlas package to encourage packaging of the new stable
 version (3.8.2). Filing a ticket on numpy trac may help, but the fate of 
ticket 667 seems to indicate that there's no will of fixing this bug upstream...

thank you, 
tiziano


  



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]