#4776 is definitely a separate issue. #4007 could be related similar f2c
ABI issues, but I don't think so. The difference between the gfotran and
g77/f2c ABIs, to my knowledge, is that (1) fortran REAL (single precision
floating point) return values are actually returned as a c double, not a c
float. (2) when return values are complex, the function is actually
implemented with an ABI that looks like a c function with an extra
pass-by-reference argument at the front of the function where the return
value is placed.
Despite the differences in the handling of the return values, I don't think
there is any difference in how float32 parameters are passed *in*, so I'm
not sure that these issues are related to subroutines like SGEMV which is
presumably behind #4007.
-Robert
On Sun, Jun 8, 2014 at 8:33 PM, Matthew Brett
Hi,
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
On Mon, Jun 9, 2014 at 2:31 AM, Robert McGibbon
wrote: 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.
Is it possible this is related to:
https://github.com/numpy/numpy/issues/4007
or even:
https://github.com/numpy/numpy/issues/4776
?
Best,
Matthew _______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion