[SciPy-User] bug report + feature request (was: scipy cblas return value)

[Radim Řehůřek]

I guess I was too verbose, let me rephrase:

1. BUG REPORT
`scipy.linalg.blas.sdot` gives wrong results on mac:

>>> scipy.linalg.blas.sdot(np.array([ 10.], dtype=np.float32), np.array([ 
0.01], dtype=np.float32))
-0.0

2. FEATURE REQUEST
Expose the way scipy internally wraps whatever BLAS it uses in C, with a 
stable, python-less API.

I already hacked around both points, because I had to. I don't know how 
much work #2 would be, whether f2py supports it or whatever magic, just 
that having it would be awesome indeed.

-rr


On Wednesday, September 25, 2013 5:22:23 PM UTC+2, Sturla Molden wrote:
>
> On Sep 24, 2013, at 11:55 PM, Radim Řehůřek <m... at radimrehurek.com<javascript:>> 
> wrote:
>
>
> But I don't know what BLAS/compiler the users will be using. 
>
>
> Then you're screwed. 
>
>
> That was the whole point of trying to go through SciPy -- I thought there 
> was a translation/interface that would allow me to call the standard 
> routines in a stable way, no matter what idiosyncratic BLAS hid 
> underneath... I figured SciPy itself must be doing that already.
>
>
>
> BLAS has a standard Fortran API. The exact ABI is compiler dependent. That 
> is all you get to know. (Note the difference between API and ABI.)
>
> SciPy uses f2py to call Fortran. f2py knows the ABI of different 
> compilers, and can thus generate wrappers for different Fortran compilers. 
>
> It is the exposed Python interface that is "standard".
>
>
> Aha. Ok. I'm sifting through the SciPy sources now, to better understand 
> what wraps what, where... it may take a while.
>
>
> You don't see the C wrappers the the SciPy sources. They are generated at 
> build-time by f2py. 
>
> You only see the interface (.pyf) files for f2py. Or actually, you see the 
> .src files used to generate the .pyf files for different dtypes.
>
>
>
> In the meanwhile, does my original idea make any sense? To let SciPy do 
> all the necessary wrapping/compiling/linking, but otherwise offer BLAS 
> using the smallest call overhead possible, with a stable signature. I know 
> the strides and all, I don't need any extra ifs or input checks or Python.
>
>
> It is a bad idea if you don't know which BLAS library will be used due to 
> different ABIs.
>
> Use SciPy if the Python overhead is small compared to the computation, and 
> then call trough the Python interface. 
>
> Otherwise I strongly recommend to use a BLAS library you can control. The 
> common ones:
>
> - Intel MKL
> - Apple Accelerate Framework
> - OpenBLAS (or GotoBLAS2)
> - AMD's ACML
> - ATLAS
>
>
> Sturla
>
>
>
>
>
>
>
>
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.scipy.org/pipermail/scipy-user/attachments/20130926/bdd058ba/attachment.html>