![](https://secure.gravatar.com/avatar/96dd777e397ab128fedab46af97a3a4a.jpg?s=120&d=mm&r=g)
Hi All, I'm pleased to announce that Numpy 1.11.0b1 <http://sourceforge.net/projects/numpy/files/NumPy/1.11.0b1/> is now available on sourceforge. This is a source release as the mingw32 toolchain is broken. Please test it out and report any errors that you discover. Hopefully we can do better with 1.11.0 than we did with 1.10.0 ;) Chuck
![](https://secure.gravatar.com/avatar/7431612bd9d490e3497f94740b7da0db.jpg?s=120&d=mm&r=g)
Hi Chuck,
I'm pleased to announce that Numpy 1.11.0b1 is now available on sourceforge. This is a source release as the mingw32 toolchain is broken. Please test it out and report any errors that you discover. Hopefully we can do better with 1.11.0 than we did with 1.10.0 ;)
the tarball seems to be incomplete, hope that does not bode ill ;-) adding 'build/src.macosx-10.10-x86_64-2.7/numpy/core/include/numpy/_numpyconfig.h' to sources. executing numpy/core/code_generators/generate_numpy_api.py error: [Errno 2] No such file or directory: 'numpy/core/code_generators/../src/multiarray/arraytypes.c.src'
FWIW, the maintenance/1.11.x branch (there is no tag for the beta?) builds and passes all tests with Python 2.7.11 and 3.5.1 on Mac OS X 10.10. Cheers, Derek
![](https://secure.gravatar.com/avatar/96dd777e397ab128fedab46af97a3a4a.jpg?s=120&d=mm&r=g)
On Tue, Jan 26, 2016 at 4:48 PM, Derek Homeier < derek@astro.physik.uni-goettingen.de> wrote:
Grr, yes indeed, `paver sdist` doesn't do the right thing, none of the `multiarray/*.c.src` files are included, but it works fine in 1.10.x. The changes are minimal, the only thing that would seem to matter is the removal of setupegg.py. Ralf, any ideas.
You probably didn't fetch the tags, if they can't be reached from the branch head they don't download automatically. Try `git fetch --tags upstream` Chuck
![](https://secure.gravatar.com/avatar/5f88830d19f9c83e2ddfd913496c5025.jpg?s=120&d=mm&r=g)
On Wed, Jan 27, 2016 at 4:47 AM, Charles R Harris <charlesr.harris@gmail.com
wrote:
Setuptools starts build_src, don't know why yet but it doesn't look to me like it should be doing that. Issue for more detailed discussion: https://github.com/numpy/numpy/issues/7127 Ralf
![](https://secure.gravatar.com/avatar/7dd64dbe40f809b9f8276bde56c872fd.jpg?s=120&d=mm&r=g)
Why the dot function/method is slower than @ on python 3.5.1? Tested from the latest 1.11 maintenance branch. np.__version__ Out[39]: '1.11.0.dev0+Unknown' %timeit A @ c 10000 loops, best of 3: 185 µs per loop %timeit A.dot(c) 1000 loops, best of 3: 526 µs per loop %timeit np.dot(A,c) 1000 loops, best of 3: 527 µs per loop A.dtype, A.shape, A.flags Out[43]: (dtype('float32'), (100, 100, 3), C_CONTIGUOUS : True F_CONTIGUOUS : False OWNDATA : True WRITEABLE : True ALIGNED : True UPDATEIFCOPY : False) c.dtype, c.shape, c.flags Out[44]: (dtype('float32'), (3, 3), C_CONTIGUOUS : True F_CONTIGUOUS : False OWNDATA : True WRITEABLE : True ALIGNED : True UPDATEIFCOPY : False) From: NumPy-Discussion <numpy-discussion-bounces@scipy.org> on behalf of Charles R Harris <charlesr.harris@gmail.com> Sent: 26 January 2016 22:49 To: numpy-discussion; SciPy Developers List; SciPy Users List Subject: [Numpy-discussion] Numpy 1.11.0b1 is out Hi All, I'm pleased to announce that Numpy 1.11.0b1 is now available on sourceforge. This is a source release as the mingw32 toolchain is broken. Please test it out and report any errors that you discover. Hopefully we can do better with 1.11.0 than we did with 1.10.0 ;) Chuck
![](https://secure.gravatar.com/avatar/b4f6d4f8b501cb05fd054944a166a121.jpg?s=120&d=mm&r=g)
On Mi, 2016-01-27 at 11:19 +0000, Nadav Horesh wrote:
Why the dot function/method is slower than @ on python 3.5.1? Tested from the latest 1.11 maintenance branch.
The explanation I think is that you do not have a blas optimization. In which case the fallback mode is probably faster in the @ case (since it has SSE2 optimization by using einsum, while np.dot does not do that). Btw. thanks for all the work getting this done Chuck! - Sebastian
![](https://secure.gravatar.com/avatar/7431612bd9d490e3497f94740b7da0db.jpg?s=120&d=mm&r=g)
On 27 Jan 2016, at 1:10 pm, Sebastian Berg <sebastian@sipsolutions.net> wrote:
I am a bit confused now, as A @ c is just short for A.__matmul__(c) or equivalent to np.matmul(A,c), so why would these not use the optimised blas? Also, I am getting almost identical results on my Mac, yet I thought numpy would by default build against the VecLib optimised BLAS. If I build explicitly against ATLAS, I am actually seeing slightly slower results. But I also saw these kind of warnings on the first timeit runs: %timeit A.dot(c) The slowest run took 6.91 times longer than the fastest. This could mean that an intermediate result is being cached and when testing much larger arrays, the discrepancy between matmul and dot rather increases, so perhaps this is more an issue of a less memory-efficient implementation in np.dot? Cheers, Derek
![](https://secure.gravatar.com/avatar/b4f6d4f8b501cb05fd054944a166a121.jpg?s=120&d=mm&r=g)
On Sa, 2016-01-30 at 20:27 +0100, Derek Homeier wrote:
Sorry, I missed the fact that one of the arrays was 3D. In that case I am not even sure which if the functions call into blas or what else they have to do, would have to check. Note that `np.dot` uses a different type of combinging high dimensional arrays. @/matmul broadcasts extra axes, while np.dot will do the outer combination of them, so that the result is: As = A.shape As.pop(-1) cs = c.shape cs.pop(-2) # if possible result_shape = As + cs which happens to be identical if only A.ndim > 2 and c.ndim <= 2. - Sebastian
![](https://secure.gravatar.com/avatar/7431612bd9d490e3497f94740b7da0db.jpg?s=120&d=mm&r=g)
Makes sense now; with A.ndim = 2 both operations take about the same time (and are ~50% faster with VecLib than with ATLAS) and yield identical results, while any additional dimension in A adds more overhead time to np.dot, and the results are np.allclose, but not exactly identical. Thanks, Derek
![](https://secure.gravatar.com/avatar/7431612bd9d490e3497f94740b7da0db.jpg?s=120&d=mm&r=g)
Hi Chuck,
I'm pleased to announce that Numpy 1.11.0b1 is now available on sourceforge. This is a source release as the mingw32 toolchain is broken. Please test it out and report any errors that you discover. Hopefully we can do better with 1.11.0 than we did with 1.10.0 ;)
the tarball seems to be incomplete, hope that does not bode ill ;-) adding 'build/src.macosx-10.10-x86_64-2.7/numpy/core/include/numpy/_numpyconfig.h' to sources. executing numpy/core/code_generators/generate_numpy_api.py error: [Errno 2] No such file or directory: 'numpy/core/code_generators/../src/multiarray/arraytypes.c.src'
FWIW, the maintenance/1.11.x branch (there is no tag for the beta?) builds and passes all tests with Python 2.7.11 and 3.5.1 on Mac OS X 10.10. Cheers, Derek
![](https://secure.gravatar.com/avatar/96dd777e397ab128fedab46af97a3a4a.jpg?s=120&d=mm&r=g)
On Tue, Jan 26, 2016 at 4:48 PM, Derek Homeier < derek@astro.physik.uni-goettingen.de> wrote:
Grr, yes indeed, `paver sdist` doesn't do the right thing, none of the `multiarray/*.c.src` files are included, but it works fine in 1.10.x. The changes are minimal, the only thing that would seem to matter is the removal of setupegg.py. Ralf, any ideas.
You probably didn't fetch the tags, if they can't be reached from the branch head they don't download automatically. Try `git fetch --tags upstream` Chuck
![](https://secure.gravatar.com/avatar/5f88830d19f9c83e2ddfd913496c5025.jpg?s=120&d=mm&r=g)
On Wed, Jan 27, 2016 at 4:47 AM, Charles R Harris <charlesr.harris@gmail.com
wrote:
Setuptools starts build_src, don't know why yet but it doesn't look to me like it should be doing that. Issue for more detailed discussion: https://github.com/numpy/numpy/issues/7127 Ralf
![](https://secure.gravatar.com/avatar/7dd64dbe40f809b9f8276bde56c872fd.jpg?s=120&d=mm&r=g)
Why the dot function/method is slower than @ on python 3.5.1? Tested from the latest 1.11 maintenance branch. np.__version__ Out[39]: '1.11.0.dev0+Unknown' %timeit A @ c 10000 loops, best of 3: 185 µs per loop %timeit A.dot(c) 1000 loops, best of 3: 526 µs per loop %timeit np.dot(A,c) 1000 loops, best of 3: 527 µs per loop A.dtype, A.shape, A.flags Out[43]: (dtype('float32'), (100, 100, 3), C_CONTIGUOUS : True F_CONTIGUOUS : False OWNDATA : True WRITEABLE : True ALIGNED : True UPDATEIFCOPY : False) c.dtype, c.shape, c.flags Out[44]: (dtype('float32'), (3, 3), C_CONTIGUOUS : True F_CONTIGUOUS : False OWNDATA : True WRITEABLE : True ALIGNED : True UPDATEIFCOPY : False) From: NumPy-Discussion <numpy-discussion-bounces@scipy.org> on behalf of Charles R Harris <charlesr.harris@gmail.com> Sent: 26 January 2016 22:49 To: numpy-discussion; SciPy Developers List; SciPy Users List Subject: [Numpy-discussion] Numpy 1.11.0b1 is out Hi All, I'm pleased to announce that Numpy 1.11.0b1 is now available on sourceforge. This is a source release as the mingw32 toolchain is broken. Please test it out and report any errors that you discover. Hopefully we can do better with 1.11.0 than we did with 1.10.0 ;) Chuck
![](https://secure.gravatar.com/avatar/b4f6d4f8b501cb05fd054944a166a121.jpg?s=120&d=mm&r=g)
On Mi, 2016-01-27 at 11:19 +0000, Nadav Horesh wrote:
Why the dot function/method is slower than @ on python 3.5.1? Tested from the latest 1.11 maintenance branch.
The explanation I think is that you do not have a blas optimization. In which case the fallback mode is probably faster in the @ case (since it has SSE2 optimization by using einsum, while np.dot does not do that). Btw. thanks for all the work getting this done Chuck! - Sebastian
![](https://secure.gravatar.com/avatar/7431612bd9d490e3497f94740b7da0db.jpg?s=120&d=mm&r=g)
On 27 Jan 2016, at 1:10 pm, Sebastian Berg <sebastian@sipsolutions.net> wrote:
I am a bit confused now, as A @ c is just short for A.__matmul__(c) or equivalent to np.matmul(A,c), so why would these not use the optimised blas? Also, I am getting almost identical results on my Mac, yet I thought numpy would by default build against the VecLib optimised BLAS. If I build explicitly against ATLAS, I am actually seeing slightly slower results. But I also saw these kind of warnings on the first timeit runs: %timeit A.dot(c) The slowest run took 6.91 times longer than the fastest. This could mean that an intermediate result is being cached and when testing much larger arrays, the discrepancy between matmul and dot rather increases, so perhaps this is more an issue of a less memory-efficient implementation in np.dot? Cheers, Derek
![](https://secure.gravatar.com/avatar/b4f6d4f8b501cb05fd054944a166a121.jpg?s=120&d=mm&r=g)
On Sa, 2016-01-30 at 20:27 +0100, Derek Homeier wrote:
Sorry, I missed the fact that one of the arrays was 3D. In that case I am not even sure which if the functions call into blas or what else they have to do, would have to check. Note that `np.dot` uses a different type of combinging high dimensional arrays. @/matmul broadcasts extra axes, while np.dot will do the outer combination of them, so that the result is: As = A.shape As.pop(-1) cs = c.shape cs.pop(-2) # if possible result_shape = As + cs which happens to be identical if only A.ndim > 2 and c.ndim <= 2. - Sebastian
![](https://secure.gravatar.com/avatar/7431612bd9d490e3497f94740b7da0db.jpg?s=120&d=mm&r=g)
Makes sense now; with A.ndim = 2 both operations take about the same time (and are ~50% faster with VecLib than with ATLAS) and yield identical results, while any additional dimension in A adds more overhead time to np.dot, and the results are np.allclose, but not exactly identical. Thanks, Derek
participants (5)
-
Charles R Harris
-
Derek Homeier
-
Nadav Horesh
-
Ralf Gommers
-
Sebastian Berg