Dear tiziano,
On Sat, Feb 23, 2008 at 11:28:22AM -0800, [EMAIL PROTECTED] wrote:
and the following code snippet was added to the file:
if ('NO_ATLAS_INFO',1) in blas_info.get('define_macros',[]):
return None # dotblas needs ATLAS, Fortran compiled blas will
not be
On Fri, Feb 22, 2008 at 8:40 PM, [EMAIL PROTECTED]
[EMAIL PROTECTED] wrote:
Hi! Unfortunately I don't think I'll manage to investigate this further
today, I'll try to have a look at it in the week end.
Regarding the _dotblas.so problem:
- on an etch system
$ ldd
I think I found out where the problem is.
In upstream numpy svn repository, in numpy/core/setup.py I found the
following log entry:
Fix: _dotblas will not ork with fortran compiled blas.
r3834 | cookedm | 2007-05-28 19:47:47
Package: python-numpy
Version: 1:1.0.4-6
Followup-For: Bug #464784
After transition to gfortran it appears that the matrix
multiplication function (numpy.dot) is now linked to the slow
version in numpy/core/multiarray.so instead of being linked to the
faster ATLAS version (in previous package
On Fri, Feb 22, 2008 at 4:09 PM, [EMAIL PROTECTED] wrote:
Package: python-numpy
Version: 1:1.0.4-6
Followup-For: Bug #464784
After transition to gfortran it appears that the matrix
multiplication function (numpy.dot) is now linked to the slow
version in numpy/core/multiarray.so
Hi! Unfortunately I don't think I'll manage to investigate this further today,
I'll try to have a look at it in the week end.
Regarding the _dotblas.so problem:
- on an etch system
$ ldd /usr/lib/python2.4/site-packages/numpy/core/_dotblas.so
linux-gate.so.1 = (0xe000)
I
would
suggest
to
add
a
Depends:
liblapack3-dev
This of course does not make any sense. It's my module which needs lapack3-dev,
not numpy, which is perfectly functional without it! Sorry!
Writing emails five minutes before living work is never a good idea :-)
ciao,
tiziano
7 matches
Mail list logo
