![](https://secure.gravatar.com/avatar/96dd777e397ab128fedab46af97a3a4a.jpg?s=120&d=mm&r=g)
Hi All, On behalf of the NumPy team I'm pleased to announce the release of NumPy 1.15.0rc1. This release has an unusual number of cleanups, many deprecations of old functions, and improvements to many existing functions. A total of 423 pull reguests were merged for this release, please look at the release notes <https://github.com/numpy/numpy/releases/tag/v1.15.0rc1>for details. Some highlights are: - NumPy has switched to pytest for testing. - A new `numpy.printoptions` context manager. - Many improvements to the histogram functions. - Support for unicode field names in python 2.7. - Improved support for PyPy. The Python versions supported by this release are 2.7, 3.4-3.6. The wheels are linked with OpenBLAS 3.0, which should fix some of the linalg problems reported for NumPy 1.14, and the source archives were created using Cython 0.28.2 and should work with the upcoming Python 3.7. Wheels for this release can be downloaded from PyPI <https://pypi.org/project/numpy/#description>, source archives are available from Github <https://github.com/numpy/numpy/releases/tag/v1.15.0rc1>. A total of 128 people contributed to this release. People with a "+" by their names contributed a patch for the first time. - Aaron Critchley + - Aarthi + - Aarthi Agurusa + - Alex Thomas + - Alexander Belopolsky - Allan Haldane - Anas Khan + - Andras Deak - Andrey Portnoy + - Anna Chiara - Aurelien Jarno + - Baurzhan Muftakhidinov - Berend Kapelle + - Bernhard M. Wiedemann - Bjoern Thiel + - Bob Eldering - Cenny Wenner + - Charles Harris - ChloeColeongco + - Chris Billington + - Christopher + - Chun-Wei Yuan + - Claudio Freire + - Daniel Smith - Darcy Meyer + - David Abdurachmanov + - David Freese - Deepak Kumar Gouda + - Dennis Weyland + - Derrick Williams + - Dmitriy Shalyga + - Eric Cousineau + - Eric Larson - Eric Wieser - Evgeni Burovski - Frederick Lefebvre + - Gaspar Karm + - Geoffrey Irving - Gerhard Hobler + - Gerrit Holl - Guo Ci + - Hameer Abbasi + - Han Shen - Hiroyuki V. Yamazaki + - Hong Xu - Ihor Melnyk + - Jaime Fernandez - Jake VanderPlas + - James Tocknell + - Jarrod Millman - Jeff VanOss + - John Kirkham - Jonas Rauber + - Jonathan March + - Joseph Fox-Rabinovitz - Julian Taylor - Junjie Bai + - Juris Bogusevs + - Jörg Döpfert - Kenichi Maehashi + - Kevin Sheppard - Kimikazu Kato + - Kirit Thadaka + - Kritika Jalan + - Lakshay Garg + - Lars G + - Licht Takeuchi - Louis Potok + - Luke Zoltan Kelley - MSeifert04 + - Mads R. B. Kristensen + - Malcolm Smith + - Mark Harfouche + - Marten H. van Kerkwijk + - Marten van Kerkwijk - Matheus Vieira Portela + - Mathieu Lamarre - Mathieu Sornay + - Matthew Brett - Matthew Rocklin + - Matthias Bussonnier - Matti Picus - Michael Droettboom - Miguel Sánchez de León Peque + - Mike Toews + - Milo + - Nathaniel J. Smith - Nelle Varoquaux - Nicholas Nadeau + - Nick Minkyu Lee + - Nikita + - Nikita Kartashov + - Nils Becker + - Oleg Zabluda - Orestis Floros + - Pat Gunn + - Paul van Mulbregt + - Pauli Virtanen - Pierre Chanial + - Ralf Gommers - Raunak Shah + - Robert Kern - Russell Keith-Magee + - Ryan Soklaski + - Samuel Jackson + - Sebastian Berg - Siavash Eliasi + - Simon Conseil - Simon Gibbons - Stefan Krah + - Stefan van der Walt - Stephan Hoyer - Subhendu + - Subhendu Ranjan Mishra + - Tai-Lin Wu + - Tobias Fischer + - Toshiki Kataoka + - Tyler Reddy + - Varun Nayyar - Victor Rodriguez + - Warren Weckesser - Zane Bradley + - fo40225 - lumbric + - luzpaz + - mamrehn + - tynn + - xoviat Cheers Chuck
![](https://secure.gravatar.com/avatar/16afbe4d5f7d86de8aa279adae4945d4.jpg?s=120&d=mm&r=g)
just checking: in Debian we're currently linking against libblas/liblapack (as available from http://www.netlib.org/lapack/) - should we start investigating switching to OpenBLAS? Thanks! -- Sandro "morph" Tosi My website: http://sandrotosi.me/ Me at Debian: http://wiki.debian.org/SandroTosi G+: https://plus.google.com/u/0/+SandroTosi
![](https://secure.gravatar.com/avatar/5f88830d19f9c83e2ddfd913496c5025.jpg?s=120&d=mm&r=g)
On Sun, Jul 8, 2018 at 7:35 PM, Sandro Tosi <sandro.tosi@gmail.com> wrote:
Yes I'd say so, the performance difference can be very large. I always thought Debian was linking against ATLAS - just because it's available and that's how we always recommended building on Debian/Linux from source. Plain Netlib BLAS/LAPACK is never recommended. Ralf
![](https://secure.gravatar.com/avatar/158d7ca423031a69f866131f36994fab.jpg?s=120&d=mm&r=g)
On Sun 08 Jul, 22:35 -0400, Sandro Tosi <sandro.tosi@gmail.com> wrote:
Well, as far as I can tell numpy in Debian is built using the /etc/alternatives method, i.e. you can choose which BLAS implementation to use at run time if more then one implementation is installed. In my case, it links to openblas already: """ $ ldd /usr/lib/python3/dist-packages/numpy/core/multiarray.cpython-36m-x86_64-linux-gnu.so linux-vdso.so.1 (0x00007ffe3bf7b000) libblas.so.3 => /usr/lib/x86_64-linux-gnu/libblas.so.3 (0x00007f23df471000) libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f23debaa000) libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f23de98c000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f23de5d2000) /lib64/ld-linux-x86-64.so.2 (0x00007f23df2e9000) libopenblas.so.0 => /usr/lib/x86_64-linux-gnu/libopenblas.so.0 (0x00007f23dc35f000) libgfortran.so.4 => /usr/lib/x86_64-linux-gnu/libgfortran.so.4 (0x00007f23dbf8b000) libquadmath.so.0 => /usr/lib/x86_64-linux-gnu/libquadmath.so.0 (0x00007f23dbd4b000) libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007f23dbb2d000) libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f23db915000) $ ls -l /usr/lib/x86_64-linux-gnu/libblas.so.3 lrwxrwxrwx 1 root root 47 Sep 11 2017 /usr/lib/x86_64-linux-gnu/libblas.so.3 -> /etc/alternatives/libblas.so.3-x86_64-linux-gnu $ ls -l /etc/alternatives/libblas.so.3-x86_64-linux-gnu lrwxrwxrwx 1 root root 47 Sep 11 2017 /etc/alternatives/libblas.so.3-x86_64-linux-gnu -> /usr/lib/x86_64-linux-gnu/openblas/libblas.so.3 $ update-alternatives --display libblas.so.3-x86_64-linux-gnu libblas.so.3-x86_64-linux-gnu - auto mode link best version is /usr/lib/x86_64-linux-gnu/openblas/libblas.so.3 link currently points to /usr/lib/x86_64-linux-gnu/openblas/libblas.so.3 link libblas.so.3-x86_64-linux-gnu is /usr/lib/x86_64-linux-gnu/libblas.so.3 /usr/lib/x86_64-linux-gnu/atlas/libblas.so.3 - priority 35 /usr/lib/x86_64-linux-gnu/blas/libblas.so.3 - priority 10 /usr/lib/x86_64-linux-gnu/openblas/libblas.so.3 - priority 40 """ So, it seems to me there's no problem to solve in Debian? Ciao! Tiziano
![](https://secure.gravatar.com/avatar/16afbe4d5f7d86de8aa279adae4945d4.jpg?s=120&d=mm&r=g)
just checking: in Debian we're currently linking against libblas/liblapack (as available from http://www.netlib.org/lapack/) - should we start investigating switching to OpenBLAS? Thanks! -- Sandro "morph" Tosi My website: http://sandrotosi.me/ Me at Debian: http://wiki.debian.org/SandroTosi G+: https://plus.google.com/u/0/+SandroTosi
![](https://secure.gravatar.com/avatar/5f88830d19f9c83e2ddfd913496c5025.jpg?s=120&d=mm&r=g)
On Sun, Jul 8, 2018 at 7:35 PM, Sandro Tosi <sandro.tosi@gmail.com> wrote:
Yes I'd say so, the performance difference can be very large. I always thought Debian was linking against ATLAS - just because it's available and that's how we always recommended building on Debian/Linux from source. Plain Netlib BLAS/LAPACK is never recommended. Ralf
![](https://secure.gravatar.com/avatar/158d7ca423031a69f866131f36994fab.jpg?s=120&d=mm&r=g)
On Sun 08 Jul, 22:35 -0400, Sandro Tosi <sandro.tosi@gmail.com> wrote:
Well, as far as I can tell numpy in Debian is built using the /etc/alternatives method, i.e. you can choose which BLAS implementation to use at run time if more then one implementation is installed. In my case, it links to openblas already: """ $ ldd /usr/lib/python3/dist-packages/numpy/core/multiarray.cpython-36m-x86_64-linux-gnu.so linux-vdso.so.1 (0x00007ffe3bf7b000) libblas.so.3 => /usr/lib/x86_64-linux-gnu/libblas.so.3 (0x00007f23df471000) libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f23debaa000) libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f23de98c000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f23de5d2000) /lib64/ld-linux-x86-64.so.2 (0x00007f23df2e9000) libopenblas.so.0 => /usr/lib/x86_64-linux-gnu/libopenblas.so.0 (0x00007f23dc35f000) libgfortran.so.4 => /usr/lib/x86_64-linux-gnu/libgfortran.so.4 (0x00007f23dbf8b000) libquadmath.so.0 => /usr/lib/x86_64-linux-gnu/libquadmath.so.0 (0x00007f23dbd4b000) libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007f23dbb2d000) libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f23db915000) $ ls -l /usr/lib/x86_64-linux-gnu/libblas.so.3 lrwxrwxrwx 1 root root 47 Sep 11 2017 /usr/lib/x86_64-linux-gnu/libblas.so.3 -> /etc/alternatives/libblas.so.3-x86_64-linux-gnu $ ls -l /etc/alternatives/libblas.so.3-x86_64-linux-gnu lrwxrwxrwx 1 root root 47 Sep 11 2017 /etc/alternatives/libblas.so.3-x86_64-linux-gnu -> /usr/lib/x86_64-linux-gnu/openblas/libblas.so.3 $ update-alternatives --display libblas.so.3-x86_64-linux-gnu libblas.so.3-x86_64-linux-gnu - auto mode link best version is /usr/lib/x86_64-linux-gnu/openblas/libblas.so.3 link currently points to /usr/lib/x86_64-linux-gnu/openblas/libblas.so.3 link libblas.so.3-x86_64-linux-gnu is /usr/lib/x86_64-linux-gnu/libblas.so.3 /usr/lib/x86_64-linux-gnu/atlas/libblas.so.3 - priority 35 /usr/lib/x86_64-linux-gnu/blas/libblas.so.3 - priority 10 /usr/lib/x86_64-linux-gnu/openblas/libblas.so.3 - priority 40 """ So, it seems to me there's no problem to solve in Debian? Ciao! Tiziano
participants (4)
-
Charles R Harris
-
Ralf Gommers
-
Sandro Tosi
-
Tiziano Zito