David M. Cooke wrote: > On Dec 10, 2007, at 10:30 , Matthieu Brucher wrote: >> 2007/12/10, Alexander Michael <[EMAIL PROTECTED]>: On Dec 10, 2007 >> 6:48 AM, David Cournapeau <[EMAIL PROTECTED]> wrote: >>> Hi, >>> >>> Several people reported problems with numpy 1.0.4 (See #627 and >>> #628, but also other problems mentionned on the ML, which I cannot >>> find). They were all solved, as far as I know, by a binary I >> produced >>> (simply using mingw + netlib BLAS/LAPACK, no ATLAS). Maybe it >> would be >>> good to use those instead ? (I can recompile them if there is a >> special >>> thing to do to build them) >> Do I understand correctly that you are suggesting removing ATLAS from >> the Windows distribution? Wouldn't this make numpy very slow? I know >> on RHEL5 I see a very large improvement between the basic BLAS/LAPACK >> and ATLAS. Perhaps we should make an alternative Windows binary >> available without ATLAS just for those having problems with ATLAS? >> That's why David proposed the netlib version of BLAS/LAPACK and not >> the default implementation in numpy. >> >> I would agree with David ;) > > Our versions of BLAS/LAPACK are f2c'd versions of the netlib 3.0 BLAS/ > LAPACK (actually, of Debian's version of these -- they include several > fixes that weren't upstream). > > So netlib's versions aren't going to be any faster, really. And > netlib's BLAS is slow. Now, if there is a BLAS that's easier to > compile than ATLAS on windows, that'd be improvement.
The current situation is untenable. I will gladly accept a slow BLAS for an official binary that won't segfault anywhere. We can look for a faster BLAS later. -- Robert Kern "I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth." -- Umberto Eco _______________________________________________ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
