Bug#464784: python-numpy please transition to gfortran/libblas-dev/lapack-dev
Ondrej Certik wrote: Thanks David for the explanation. So I am not going to do anything for this bug. However, if anyone knows what to do, please let us know. Feel free to discuss it on the debian-python mailinglist and then fix the package in our svn. Well, actually, contrary to what I've said earlier, there is cblas available in the new blas package (in hardy, which is why I have not seen it; I don't use debian anymore for non server machines). So one solution could be to build numpy against blas/lapack/cblas packages, making sure the CBLAS is found, and then, people could install atlas to change the runtime libraries. Now, I am not sure whether numpy can currently build against the standard CBLAS. I know it can build against ATLAS (and Intel MKL) CBLAS, but I don't know for others, cheers, David -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#464784: python-numpy please transition to gfortran/libblas-dev/lapack-dev
Hi, Following a comment done on numpy bug tracking system (ticket #667): dotblas uses the CBLAS API, and as such needs CBLAS; CBLAS functions (cblas_*) are simply not provided by BLAS. They are provided by ATLAS, though. So you cannot build dotblas with the netlib BLAS package (the one used in refblas3). This explains why numpy is 'picky' about ATLAS, more than other packages: numpy does not only use the F77 interface, but also the "official" C interface (I guess, but I am not sure, that the point is to have a fast multiplication available for numpy even if no fortran compiler is available on the building machine). To be able to replace libraries at runtime for a numpy built with ATLAS, you would need a libcblas, which is not available in debian AFAIK. So there is really no way around it: you have to wait for atlas, and built against it. cheers, David -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#400158: [Deb-scipy-devel] Bug#400158: numpy 1.0 available
Marco Presi wrote: || On Fri, 24 Nov 2006 08:48:32 +0100 || Soeren Sonnenburg <[EMAIL PROTECTED]> wrote: ss> Package: python-numpy ss> Version: 1:1.0rc1-1 ss> Severity: normal ss> we don't want to rc1 to be in sarge if there is 1.0-1 right ? ss> http://sourceforge.net/project/showfiles.php?group_id=1369&package_id=175103 Not really. Numpy 1.0 is not compatible both with current versions of scipy and matplotlib. I am myself using numpy svn (post 1.0) and scipy svn, with last release of matplotlib (0.87.7): they all work together since the release of numpy 1.0 and matplotlib 0.87.7 (0.87.6 did not work with numpy 1.0, if I remember correctly), AFAIK. Is the incompatibility specific to some architectures ? David -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
