Yeah, that's definitely not the right signature for sdot when linked against the Accelerate framework.
But what's the purpose of those wrappers in _umath_linalg? The one for sdot, for example, doesn't appear to be used internally, and it isn't available from the python side. While scipy has all of those function pointers accessible in scipy.linalg.blas (e.g. scipy.linalg.blas.sdot._cpointer), those function pointers point to the underlying blas function and expose the ABI differences between platforms, leading to, for example the utter nightmare of using the scipy blas function pointers from cython in a cross platform way: https://gist.github.com/anonymous/6659007. -Robert On Sun, Jun 8, 2014 at 5:36 PM, Sturla Molden <[email protected]> wrote: > NumPy seems to define BLAS and LAPACK functions with gfortran ABI: > > > https://github.com/numpy/numpy/blob/master/numpy/linalg/umath_linalg.c.src#L289 > > extern float > FNAME(sdot)(int *n, > float *sx, int *incx, > float *sy, int *incy); > > What happens on OS X where Accelerate Framework uses f2c ABI? SciPy has C > wrappers for Accelerate to deal with this. Should NumPy adopt those as > well? > > And while we are at it, why are LAPACK subroutines declared to return int? > I thought a Fortran subroutine should map to a void function in C. From the > same file: > > extern int > FNAME(dgesv)(int *n, int *nrhs, > double a[], int *lda, > int ipiv[], > double b[], int *ldb, > int *info); > > > Sturla > > _______________________________________________ > NumPy-Discussion mailing list > [email protected] > http://mail.scipy.org/mailman/listinfo/numpy-discussion >
_______________________________________________ NumPy-Discussion mailing list [email protected] http://mail.scipy.org/mailman/listinfo/numpy-discussion
