But I can't reproduce #4007 on my machine, so I'm not totally sure. -Robert
On Sun, Jun 8, 2014 at 9:07 PM, Robert McGibbon <rmcgi...@gmail.com> wrote: > #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 <matthew.br...@gmail.com> > wrote: > >> Hi, >> >> On Mon, Jun 9, 2014 at 2:31 AM, Robert McGibbon <rmcgi...@gmail.com> >> wrote: >> > 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. >> >> 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 >> > >
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
