[Numpy-discussion] numpy setup.py too restrictive, prevents use of fblas with cblas
Wed Apr 16 16:46:57 CDT 2008
On Wed, Apr 16, 2008 at 3:37 PM, Stéfan van der Walt <firstname.lastname@example.org> wrote:
> Hi Robert
> On 16/04/2008, Robert Kern <email@example.com> wrote:
> > The correct fix needs to be more sophisticated than removing those two
> > lines. We need to recognize the MKL and the GOTO BLAS and allow them,
> > too. It might also be worth including the appropriate subset of the
> > cblas code provided in the tarball such that we can use any
> > accelerated FORTRAN BLAS without the standard cblas interface. Then
> > George wouldn't have the build the cblas library himself, either.
> The inclusion of those cblas routines sounds like a good idea. Could
> you describe which we need, and what would be required to get this
Basically all of the files defining functions used in _dotblas.c and
their dependencies; grepping for "cblas_" should find them all. The
tricky part, naturally, is the build configuration. We need to
recognize when we have an accelerated fblas and cblas (do not use our
own cblas routines), when we have an accelerated fblas only (do use
our own cblas routines), and when we don't have anything accelerated
(do not build dotblas at all). I don't have a particularly clear idea
on how to do that cleanly.
One potential problem that I've just noticed is that there are some
Fortran files in the cblas. For the most part, these seem to be used
to convert Fortran function calls which return complex scalars to
Fortran subroutines which can be easily interfaced to C. For example
cblas_cdotu_sub.c requires cdotc.f. dotblas uses four such functions:
cblas_[cz]dot[cu]_sub(). We would have to find another way to do
these; possibly, we can just apply f2c to the Fortran files.
"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
More information about the Numpy-discussion