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 sufficient.
>
> which clearly indicates that dotblas is now, for some reason which I really
> don't know, dependent on ATLAS. To get dotblas built in, it is enough to
> remove the debian patch: 02_dontuse_lapack.diff . I tested it and the
> resulting python-numpy packages contain _dotblas.so correctly linked to
> the optimized atlas library.
>
> This of course would mean Depends: libatlas3-headers, libatlas3gf-base |
> libatlas3gf-sse2 | etc...
> I would think that the bug actually is not a bug but a wishlist item and
> that it has nothing to do with the gfortran transition.
> Would you add dependency to atlas and give numpy a manyfold speed
> improvement? I agree that not using Atlas is going to result in a huge performance penalty. However, the trouble is that Atlas has not really completed the gfortran transition, and has not yet built on all architectures yet: http://buildd.debian.org/~jeroen/status/package.php?p=atlas In case we start Build-depending on Atlas now, this would mean that we will not be able to get numpy built on these architectures. Also, numpy seems to be special, in that it seems to be very sensitive to being built against Atlas. Other packages seem to want only Blas/Lapack and happily use the Atlas system when it is installed, without a rebuild. Thanks for reporting this, but for now, I can just say you might have to rebuild with Atlas. A better suggestion to overcome this problem is welcome though. Thanks! Kumar -- Kumar Appaiah, 458, Jamuna Hostel, Indian Institute of Technology Madras, Chennai - 600 036
signature.asc
Description: Digital signature
_______________________________________________ Python-modules-team mailing list [email protected] http://lists.alioth.debian.org/mailman/listinfo/python-modules-team
