Re: [SciPy-User] scipy cblas return value
Thanks guys, these comments are very helpful. But I don't know what BLAS/compiler the users will be using. 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. But `scipy.linalg.blas.sdot` gives me the wrong result in Python, too. The same as when called from C through _cpointer. So now I'm confused -- surely this issue has something to do with SciPy? Scipy itself uses a combination of options 1 and 2, but the wrapper
functions are not exposed via _cpointer (they don't have the standard BLAS API), which points to the "raw" BLAS function.
Aha. Ok. I'm sifting through the SciPy sources now, to better understand what wraps what, where... it may take a while. 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. Cheers, Radim
On Sep 24, 2013, at 11:55 PM, Radim Řehůřek <me@radimrehurek.com> 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
On Wed, Sep 25, 2013 at 4:22 PM, Sturla Molden <sturla@molden.no> wrote:
On Sep 24, 2013, at 11:55 PM, Radim Řehůřek <me@radimrehurek.com> 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.) BLAS also has a standard C API implemented by most, if not all, reasonable implementations. No, I will go so far as to say that any modern implementation that excludes the CBLAS API is unreasonable and can be ignored. http://www.netlib.org/blas/blast-forum/cinterface.pdf For example, all of these implement the CBLAS 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
You don't have to pick just one. Just require the CBLAS interface, then you can let downstream users freely pick and choose among the many fine implementations of the CBLAS interface. -- Robert Kern
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...@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
On Sep 26, 2013, at 3:09 PM, Radim Řehůřek <me@radimrehurek.com> wrote:
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
Let me submit in evidence to the contrary: In [20]: scipy.linalg.blas.sdot(np.array([10.],dtype=np.float32),np.array([0.01],dtype=np.float32)) Out[20]: 0.09999999403953552 In [21]: sys.platform Out[21]: 'darwin' It is your BLAS library that makes the error, not SciPy. Sturla
2013/9/26 Sturla Molden <sturla@molden.no>
On Sep 26, 2013, at 3:09 PM, Radim Řehůřek <me@radimrehurek.com> wrote:
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
Let me submit in evidence to the contrary:
In [20]: scipy.linalg.blas.sdot(np.array([10.],dtype=np.float32),np.array([0.01],dtype=np.float32)) Out[20]: 0.09999999403953552
In [21]: sys.platform Out[21]: 'darwin'
It is your BLAS library that makes the error, not SciPy.
Sturla
_______________________________________________ SciPy-User mailing list SciPy-User@scipy.org http://mail.scipy.org/mailman/listinfo/scipy-user
Confirming Sturla's evidence In [9]: linalg.blas.sdot(np.array([10.],dtype=np.float32),np.array([0.01],dtype=np.float32)) Out[9]: 0.09999999403953552 In [10]: sys.platform Out[10]: 'darwin' In [11]: scipy.__version__ Out[11]: '0.12.0' -- Sasha
Or scipy is badly compiled. Since OS X does not ship with a fortran compiler it is especially hard to compile and link it properly with a blas. If you use slightly incompatible compilers there is absolutely no compile error you just get broken results out of the blas functions. On that note the only prebuilt scipy that is not broken is the one that comes with Enthough Canopy. The Anaconda one is broken. I haven't tried the standalone packages, though. 2013/9/26 Sturla Molden <sturla@molden.no>
On Sep 26, 2013, at 3:09 PM, Radim Řehůřek <me@radimrehurek.com> wrote:
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
Let me submit in evidence to the contrary:
In [20]: scipy.linalg.blas.sdot(np.array([10.],dtype=np.float32),np.array([0.01],dtype=np.float32)) Out[20]: 0.09999999403953552
In [21]: sys.platform Out[21]: 'darwin'
It is your BLAS library that makes the error, not SciPy.
Sturla
--
--- You received this message because you are subscribed to the Google Groups "cython-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to cython-users+unsubscribe@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
-- La brigade SnW veut vous recruter - http://www.brigadesnw.ca
On Thu, Sep 26, 2013 at 10:04 AM, Arnaud Bergeron <abergeron@gmail.com> wrote:
Or scipy is badly compiled. Since OS X does not ship with a fortran compiler it is especially hard to compile and link it properly with a blas. If you use slightly incompatible compilers there is absolutely no compile error you just get broken results out of the blas functions.
On that note the only prebuilt scipy that is not broken is the one that comes with Enthough Canopy.
Are you saying that the prebuilt scipy we ship with Sage is broken? I'm curious, since I can file a bug report, and I thought we had things sorted out by now, after putting a heck of a lot of work into this platform over the last 6 years... Here's our Mac binaries: http://boxen.math.washington.edu/home/sagemath/sage-mirror/osx/intel/index.h... Here's the source, which I think automatically gets things right (regarding building scipy), assuming one follows the instructions... http://boxen.math.washington.edu/home/sagemath/sage-mirror/src/index.html --William
The Anaconda one is broken. I haven't tried the standalone packages, though.
2013/9/26 Sturla Molden <sturla@molden.no>
On Sep 26, 2013, at 3:09 PM, Radim Řehůřek <me@radimrehurek.com> wrote:
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
Let me submit in evidence to the contrary:
In [20]: scipy.linalg.blas.sdot(np.array([10.],dtype=np.float32),np.array([0.01],dtype=np.float32)) Out[20]: 0.09999999403953552
In [21]: sys.platform Out[21]: 'darwin'
It is your BLAS library that makes the error, not SciPy.
Sturla
--
--- You received this message because you are subscribed to the Google Groups "cython-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to cython-users+unsubscribe@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
-- La brigade SnW veut vous recruter - http://www.brigadesnw.ca
--
--- You received this message because you are subscribed to the Google Groups "cython-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to cython-users+unsubscribe@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
-- William Stein Professor of Mathematics University of Washington http://wstein.org
2013/9/26 William Stein <wstein@gmail.com>
On Thu, Sep 26, 2013 at 10:04 AM, Arnaud Bergeron <abergeron@gmail.com> wrote:
Or scipy is badly compiled. Since OS X does not ship with a fortran compiler it is especially hard to compile and link it properly with a blas. If you use slightly incompatible compilers there is absolutely no compile error you just get broken results out of the blas functions.
On that note the only prebuilt scipy that is not broken is the one that comes with Enthough Canopy.
Are you saying that the prebuilt scipy we ship with Sage is broken? I'm curious, since I can file a bug report, and I thought we had things sorted out by now, after putting a heck of a lot of work into this platform over the last 6 years... Here's our Mac binaries:
http://boxen.math.washington.edu/home/sagemath/sage-mirror/osx/intel/index.h...
Sage isn't just a python distribution :) It's also not listed on the scipy install page. But still, the scipy binaries that come with it are broken (at least for the 10.6 package I tried). If you try the command above it returns -0.0 rather than the correct 0.09999999403953552.
Here's the source, which I think automatically gets things right (regarding building scipy), assuming one follows the instructions...
http://boxen.math.washington.edu/home/sagemath/sage-mirror/src/index.html
--William
The Anaconda one is broken. I haven't tried the standalone packages, though.
2013/9/26 Sturla Molden <sturla@molden.no>
On Sep 26, 2013, at 3:09 PM, Radim Řehůřek <me@radimrehurek.com> wrote:
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
Let me submit in evidence to the contrary:
In [20]:
scipy.linalg.blas.sdot(np.array([10.],dtype=np.float32),np.array([0.01],dtype=np.float32))
Out[20]: 0.09999999403953552
In [21]: sys.platform Out[21]: 'darwin'
It is your BLAS library that makes the error, not SciPy.
Sturla
--
--- You received this message because you are subscribed to the Google Groups "cython-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to cython-users+unsubscribe@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
-- La brigade SnW veut vous recruter - http://www.brigadesnw.ca
--
--- You received this message because you are subscribed to the Google Groups "cython-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to cython-users+unsubscribe@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
-- William Stein Professor of Mathematics University of Washington http://wstein.org
--
--- You received this message because you are subscribed to the Google Groups "cython-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to cython-users+unsubscribe@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
On Thu, Sep 26, 2013 at 11:35 AM, Arnaud Bergeron <abergeron@gmail.com> wrote:
2013/9/26 William Stein <wstein@gmail.com>
On Thu, Sep 26, 2013 at 10:04 AM, Arnaud Bergeron <abergeron@gmail.com> wrote:
Or scipy is badly compiled. Since OS X does not ship with a fortran compiler it is especially hard to compile and link it properly with a blas. If you use slightly incompatible compilers there is absolutely no compile error you just get broken results out of the blas functions.
On that note the only prebuilt scipy that is not broken is the one that comes with Enthough Canopy.
Are you saying that the prebuilt scipy we ship with Sage is broken? I'm curious, since I can file a bug report, and I thought we had things sorted out by now, after putting a heck of a lot of work into this platform over the last 6 years... Here's our Mac binaries:
http://boxen.math.washington.edu/home/sagemath/sage-mirror/osx/intel/index.h...
Sage isn't just a python distribution :) It's also not listed on the scipy install page.
OK, good point :-)
But still, the scipy binaries that come with it are broken (at least for the 10.6 package I tried). If you try the command above it returns -0.0 rather than the correct 0.09999999403953552.
Ugh. Many thanks for the bug report.
Here's the source, which I think automatically gets things right (regarding building scipy), assuming one follows the instructions...
http://boxen.math.washington.edu/home/sagemath/sage-mirror/src/index.html
--William
The Anaconda one is broken. I haven't tried the standalone packages, though.
2013/9/26 Sturla Molden <sturla@molden.no>
On Sep 26, 2013, at 3:09 PM, Radim Řehůřek <me@radimrehurek.com> wrote:
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
Let me submit in evidence to the contrary:
In [20]:
scipy.linalg.blas.sdot(np.array([10.],dtype=np.float32),np.array([0.01],dtype=np.float32)) Out[20]: 0.09999999403953552
In [21]: sys.platform Out[21]: 'darwin'
It is your BLAS library that makes the error, not SciPy.
Sturla
--
--- You received this message because you are subscribed to the Google Groups "cython-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to cython-users+unsubscribe@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
-- La brigade SnW veut vous recruter - http://www.brigadesnw.ca
--
--- You received this message because you are subscribed to the Google Groups "cython-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to cython-users+unsubscribe@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
-- William Stein Professor of Mathematics University of Washington http://wstein.org
--
--- You received this message because you are subscribed to the Google Groups "cython-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to cython-users+unsubscribe@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
--
--- You received this message because you are subscribed to the Google Groups "cython-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to cython-users+unsubscribe@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
-- William Stein Professor of Mathematics University of Washington http://wstein.org
That is the expected result on OSX 10.6. Well-known bug in the OSX accelerate framework which Apple never fixed.
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
2013/9/26 Volker Braun <vbraun.name@gmail.com>
That is the expected result on OSX 10.6. Well-known bug in the OSX accelerate framework which Apple never fixed.
No, that is not a bug in Accelerate. It is an ABI mismatch between what scipy expects and what vecLib provides.
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
--
--- You received this message because you are subscribed to the Google Groups "cython-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to cython-users+unsubscribe@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
On 2013-09-26, William Stein <wstein@gmail.com> wrote:
On Thu, Sep 26, 2013 at 11:35 AM, Arnaud Bergeron <abergeron@gmail.com> wrote:
2013/9/26 William Stein <wstein@gmail.com>
On Thu, Sep 26, 2013 at 10:04 AM, Arnaud Bergeron <abergeron@gmail.com> wrote:
Or scipy is badly compiled. Since OS X does not ship with a fortran compiler it is especially hard to compile and link it properly with a blas. If you use slightly incompatible compilers there is absolutely no compile error you just get broken results out of the blas functions.
On that note the only prebuilt scipy that is not broken is the one that comes with Enthough Canopy.
Are you saying that the prebuilt scipy we ship with Sage is broken? I'm curious, since I can file a bug report, and I thought we had things sorted out by now, after putting a heck of a lot of work into this platform over the last 6 years... Here's our Mac binaries:
http://boxen.math.washington.edu/home/sagemath/sage-mirror/osx/intel/index.h...
Sage isn't just a python distribution :) It's also not listed on the scipy install page.
OK, good point :-)
But still, the scipy binaries that come with it are broken (at least for the 10.6 package I tried). If you try the command above it returns -0.0 rather than the correct 0.09999999403953552.
Ugh. Many thanks for the bug report.
could be due to using binary for wrong arch. With OSX 10.6 there were lots of issues whether it's a 32-bit or 64-bit... At least on my 32-bit OSX 10.6 system self-compiled Sage 5.12.beta4 works as expected: $ uname -a Darwin nash 10.8.0 Darwin Kernel Version 10.8.0: Tue Jun 7 16:33:36 PDT 2011; root:xnu-1504.15.3~1/RELEASE_I386 i386 sage: scipy.linalg.blas.sdot(np.array([10.],dtype=np.float32),np.array([0.01],dtype=np.float32)) 0.09999999403953552 sage: version() 'Sage Version 5.12.beta4, Release Date: 2013-08-30'
Here's the source, which I think automatically gets things right (regarding building scipy), assuming one follows the instructions...
http://boxen.math.washington.edu/home/sagemath/sage-mirror/src/index.html
--William
The Anaconda one is broken. I haven't tried the standalone packages, though.
2013/9/26 Sturla Molden <sturla@molden.no>
On Sep 26, 2013, at 3:09 PM, Radim Řehůřek <me@radimrehurek.com> wrote:
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
Let me submit in evidence to the contrary:
In [20]:
scipy.linalg.blas.sdot(np.array([10.],dtype=np.float32),np.array([0.01],dtype=np.float32)) Out[20]: 0.09999999403953552
In [21]: sys.platform Out[21]: 'darwin'
It is your BLAS library that makes the error, not SciPy.
Sturla
--
--- You received this message because you are subscribed to the Google Groups "cython-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to cython-users+unsubscribe@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
-- La brigade SnW veut vous recruter - http://www.brigadesnw.ca
--
--- You received this message because you are subscribed to the Google Groups "cython-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to cython-users+unsubscribe@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
-- William Stein Professor of Mathematics University of Washington http://wstein.org
--
--- You received this message because you are subscribed to the Google Groups "cython-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to cython-users+unsubscribe@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
--
--- You received this message because you are subscribed to the Google Groups "cython-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to cython-users+unsubscribe@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
-- William Stein Professor of Mathematics University of Washington http://wstein.org
Update on this issue: To get the right results for this call: scipy.linalg.blas.sdot(np.array([10.],dtype=np.float32), np.array([0.01],dtype=np.float32)) you can compile scipy using export FOPT=-ff2c But there are still some ABI mismatches in arpack, lapack and others. Scipy 0.13 include extended ABI wrappers which should fix all of the issues related to this when linking to Accelerate. No need to use any special flags or anything. So for people looking for an easy way to fix these issues: upgrade scipy. 2013/9/27 Dima Pasechnik <dimpase@gmail.com>
On Thu, Sep 26, 2013 at 11:35 AM, Arnaud Bergeron <abergeron@gmail.com> wrote:
2013/9/26 William Stein <wstein@gmail.com>
On Thu, Sep 26, 2013 at 10:04 AM, Arnaud Bergeron <abergeron@gmail.com
wrote:
Or scipy is badly compiled. Since OS X does not ship with a fortran compiler it is especially hard to compile and link it properly with a blas. If you use slightly incompatible compilers there is absolutely no compile error you just get broken results out of the blas functions.
On that note the only prebuilt scipy that is not broken is the one
On 2013-09-26, William Stein <wstein@gmail.com> wrote: that
comes with Enthough Canopy.
Are you saying that the prebuilt scipy we ship with Sage is broken? I'm curious, since I can file a bug report, and I thought we had things sorted out by now, after putting a heck of a lot of work into this platform over the last 6 years... Here's our Mac binaries:
http://boxen.math.washington.edu/home/sagemath/sage-mirror/osx/intel/index.h...
Sage isn't just a python distribution :) It's also not listed on the scipy install page.
OK, good point :-)
But still, the scipy binaries that come with it are broken (at least
for the
10.6 package I tried). If you try the command above it returns -0.0 rather than the correct 0.09999999403953552.
Ugh. Many thanks for the bug report.
could be due to using binary for wrong arch. With OSX 10.6 there were lots of issues whether it's a 32-bit or 64-bit... At least on my 32-bit OSX 10.6 system self-compiled Sage 5.12.beta4 works as expected: $ uname -a Darwin nash 10.8.0 Darwin Kernel Version 10.8.0: Tue Jun 7 16:33:36 PDT 2011; root:xnu-1504.15.3~1/RELEASE_I386 i386
sage: scipy.linalg.blas.sdot(np.array([10.],dtype=np.float32),np.array([0.01],dtype=np.float32)) 0.09999999403953552 sage: version() 'Sage Version 5.12.beta4, Release Date: 2013-08-30'
Here's the source, which I think automatically gets things right (regarding building scipy), assuming one follows the instructions...
http://boxen.math.washington.edu/home/sagemath/sage-mirror/src/index.html
--William
The Anaconda one is broken. I haven't tried the standalone packages, though.
2013/9/26 Sturla Molden <sturla@molden.no>
On Sep 26, 2013, at 3:09 PM, Radim Řehůřek <me@radimrehurek.com>
wrote:
> 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 >
Let me submit in evidence to the contrary:
In [20]:
scipy.linalg.blas.sdot(np.array([10.],dtype=np.float32),np.array([0.01],dtype=np.float32))
Out[20]: 0.09999999403953552
In [21]: sys.platform Out[21]: 'darwin'
It is your BLAS library that makes the error, not SciPy.
Sturla
--
--- You received this message because you are subscribed to the Google Groups "cython-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to cython-users+unsubscribe@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
-- La brigade SnW veut vous recruter - http://www.brigadesnw.ca
--
--- You received this message because you are subscribed to the Google Groups "cython-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to cython-users+unsubscribe@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
-- William Stein Professor of Mathematics University of Washington http://wstein.org
--
--- You received this message because you are subscribed to the Google Groups "cython-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to cython-users+unsubscribe@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
--
--- You received this message because you are subscribed to the Google Groups "cython-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to cython-users+unsubscribe@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
-- William Stein Professor of Mathematics University of Washington http://wstein.org
--
--- You received this message because you are subscribed to the Google Groups "cython-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to cython-users+unsubscribe@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
-- La brigade SnW veut vous recruter - http://www.brigadesnw.ca
Den 26. sep. 2013 kl. 19:04 skrev Arnaud Bergeron <abergeron@gmail.com>:
Or scipy is badly compiled. Since OS X does not ship with a fortran compiler it is especially hard to compile and link it properly with a blas. If you use slightly incompatible compilers there is absolutely no compile error you just get broken results out of the blas functions.
What OS ships with a Fortran compiler today? Windows? Surely not. On a Mac, Apple GCC-LLVM is a PITA for scientific programming. It does not have gfortran, and trying to install it can produce conflicts. And as the GCC is stuck in version 4.2, we do not have C99 or C++11. There is no OpenMP due to LLVM, and Apple probably wants us to use the GCD instead of OpenMP. Accelerate Framework is a bad choice of BLAS. It is very slow comparted to Intel MKL – often four to ten times slower. Accelerate Framework also uses the "Grand Central Dispatch". The GCD cannot be used on both sides of os.fork without an os.exec*. Thus, Python programs using multiprocessing (and most programs using posix fork) will randomly fail if they use the Accelerate Framework's BLAS functions. Basically, Apple is pointing nose at us. The solution to most of these issues is to get the Intel compilers. Intel C++ Composer XE is binary compatible with Apple GCC-LLVM. It has C99, C++11, OpenMP, and also ships with the MKL. If we need Fortran it can be extended with Intel or Absoft Fortran compilers. The BLAS library in MKL uses Intel's OpenMP implementation, not the GCD, and does not randomly fail with multiprocessing or os.fork. If we absolutely want to do scientific computing with free tools on a Mac, I'd recommend running Linux in a VirtualBox VM. Otherwise it might be painful. Sturla
On 9/26/13 12:55 , Sturla Molden wrote:
Den 26. sep. 2013 kl. 19:04 skrev Arnaud Bergeron <abergeron@gmail.com>:
Or scipy is badly compiled. Since OS X does not ship with a fortran compiler it is especially hard to compile and link it properly with a blas. If you use slightly incompatible compilers there is absolutely no compile error you just get broken results out of the blas functions.
What OS ships with a Fortran compiler today? Windows? Surely not.
On a Mac, Apple GCC-LLVM is a PITA for scientific programming. It does not have gfortran, and trying to install it can produce conflicts. And as the GCC is stuck in version 4.2, we do not have C99 or C++11. There is no OpenMP due to LLVM, and Apple probably wants us to use the GCD instead of OpenMP.
Accelerate Framework is a bad choice of BLAS. It is very slow comparted to Intel MKL – often four to ten times slower. Accelerate Framework also uses the "Grand Central Dispatch". The GCD cannot be used on both sides of os.fork without an os.exec*. Thus, Python programs using multiprocessing (and most programs using posix fork) will randomly fail if they use the Accelerate Framework's BLAS functions.
Basically, Apple is pointing nose at us.
The solution to most of these issues is to get the Intel compilers. Intel C++ Composer XE is binary compatible with Apple GCC-LLVM. It has C99, C++11, OpenMP, and also ships with the MKL. If we need Fortran it can be extended with Intel or Absoft Fortran compilers. The BLAS library in MKL uses Intel's OpenMP implementation, not the GCD, and does not randomly fail with multiprocessing or os.fork.
If we absolutely want to do scientific computing with free tools on a Mac, I'd recommend running Linux in a VirtualBox VM. Otherwise it might be painful.
This is a rather narrow viewpoint. There are free-software package managers for Mac OS X, and macports is a decent one. It has its critics, but I have found it to reliably provide a working python/numpy/scipy environment including all the necessary associated libraries. Jonathan
On Sep 27, 2013, at 3:57 PM, Jonathan Stickel <jjstickel@gmail.com> wrote:
This is a rather narrow viewpoint. There are free-software package managers for Mac OS X, and macports is a decent one. It has its critics, but I have found it to reliably provide a working python/numpy/scipy environment including all the necessary associated libraries.
Personally I prefer to not install another GCC, it case it renders Xcode and system libraries fubar. Thus I rather pay for Intel compilers and SciPy from Enthought or Anaconda. A Mac will be more expensive than a Linux or Wintendo computer anyway. I just consider this a part of the additional expense. :-) I am sure there are some who will disagree. :-) Sturla
participants (9)
-
Arnaud Bergeron -
Dima Pasechnik -
Jonathan Stickel -
Oleksandr Huziy -
Radim Řehůřek -
Robert Kern -
Sturla Molden -
Volker Braun -
William Stein