Package Details: python-numpy-openblas 1.18.3-1

Git Clone URL: https://aur.archlinux.org/python-numpy-openblas.git (read-only, click to copy)
Package Base: python-numpy-openblas
Description: Scientific tools for Python - built with openblas
Upstream URL: http://numpy.scipy.org/
Licenses: custom
Conflicts: python-numpy, python3-numpy
Provides: python-numpy=1.18.3, python3-numpy=1.18.3
Submitter: xia0er
Maintainer: xia0er
Last Packager: xia0er
Votes: 24
Popularity: 0.47
First Submitted: 2013-11-21 20:38
Last Updated: 2020-04-30 05:40

Required by (1000)

Sources (1)

Latest Comments

1 2 3 4 5 6 Next › Last »

hairyass commented on 2020-05-29 02:46

I like this package because it just works. It removes all the conflicting packages, so please keep this package

E3LDDfrK commented on 2020-04-07 17:54

I was thinking about creating an ArchWiki page that explains what is BLAS & LAPACK, which packages use them, what are the available providers, and how to switch. This could be linked from the user package wikis (numpy, R, julia, etc.). Would that solve the issue in your opinion?

@mdeff That sounds great.

mdeff commented on 2020-04-07 11:35

@xia0er, thanks for your consideration. Isn't it overkill to have to rebuild the package for an additional dependency? Also, such a policy quickly explodes, as you'd need every <package>-<blas> combinations with {numpy, scipy, julia, r, pytorch, tensorflow, opencv, arpack, etc.} as packages and {netlib, openblas, mkl, blis, atlas} as blas. I think it's cleaner for user packages to depend on {blas, cblas, lapack, lapacke} and for provider packages to provide those. Users then choose which provider to install.

I was thinking about creating an ArchWiki page that explains what is BLAS & LAPACK, which packages use them, what are the available providers, and how to switch. This could be linked from the user package wikis (numpy, R, julia, etc.). Would that solve the issue in your opinion?

In the longer term, Arch should ideally allow the installation of multiple providers and have a mechanism to easily switch the default, like Debian, Gentoo, conda-forge (Arch does it for java).

Do you remember where the discussion about not including LAPACK in community/openblas happened? I searched as much as I could and didn't find any. In my opinion it's a serious issue (most serious being the omission of the C bindings), and the maintainer doesn't seem responsive. :/

xia0er commented on 2020-04-06 18:09

@mdeff Just checked out the FS#s you linked to. If the community/openblas eventually includes lapack, I agree this package can be sunset/removed, but I'd like to keep it active before that.

xia0er commented on 2020-04-06 18:04

@mdeff, the whole purpose of this package is to specify the dependency on aur/openblas-lapack. The community/openblas doesn't provide lapack (and will not, as I recall from an early discussion in the openblas package and why the aur/openblas-lapack package was created). As you pointed out, one can install aur/openblas-lapack and community/python-numpy, and have an optimized bumpy installation, but there is no clear way to specify the dependency than this package.

mdeff commented on 2020-04-06 11:34

You can check what numpy is actually dynamically linked to with ldd /usr/lib/python3.8/site-packages/numpy/core/_multiarray_umath.cpython-38-x86_64-linux-gnu.so and ldd /usr/lib/python3.8/site-packages/numpy/linalg/_umath_linalg.cpython-38-x86_64-linux-gnu.so. There will be a line about BLAS, like libblas.so.3 => /usr/lib/libblas.so.3 and a line about LAPACK, like liblapack.so.3 => /usr/lib/liblapack.so.3. Numpy links to the system-provided BLAS and LAPACK. We can check where they come from.

1) If you have extra/blas, extra/cblas, and extra/lapack installed (i.e., BLAS and LAPACK from netlib), /usr/lib/libblas.so.3 will be a symlink to /usr/lib/libblas.so.3.9.0 (owned by extra/blas), and /usr/lib/liblapack.so.3 will be a symlink to /usr/lib/liblapack.so.3.9.0 (owned by extra/lapack).

2) If you have community/openblas, extra/cblas, and extra/lapack installed (i.e., BLAS from OpenBLAS and LAPACK from netlib), /usr/lib/libblas.so.3 will be a symlink to /usr/lib/libopenblasp-r0.3.9.so (owned by community/openblas) and /usr/lib/liblapack.so.3 will be a symlink to /usr/lib/liblapack.so.3.9.0 (owned by extra/lapack). (FYI, I don't recommended this configuration. See FS#66092, FS#59046, FS#63054, FS#62558. The community/openblas package should be fixed and could replace aur/openblas-lapack.)

3) If you have aur/openblas-lapack installed (i.e., BLAS and LAPACK from OpenBLAS), /usr/lib/libblas.so.3 and /usr/lib/liblapack.so.3 will be symlinks to /usr/lib/libopenblas.so (owned by aur/openblas-lapack).

4) You can actually symlink any BLAS and LAPACK provider (e.g., MKL, ATLAS, BLIS) to those locations, and numpy and scipy, (but also R, Julia, Octave, etc.) will use them. That's because BLAS and LAPACK are defined as APIs. Those are implemented by multiple providers which can be dynamically loaded at runtime.

E3LDDfrK commented on 2020-04-05 15:36

@mdeff Is there a better way to verify it instead of timing it?

mdeff commented on 2020-04-02 20:48

As @adfjjv pointed out, the stock extra/python-numpy will use OpenBLAS if installed (by community/openblas or aur/openblas-lapack).

You can verify it empirically:

sudo pacman -S blas lapack cblas python-numpy  # BLAS and LAPACK from netlib
time python -c "import numpy as np; x=np.random.random((2000, 2000)); np.dot(x, x.T)"
# about 4 seconds on my system, single thread
sudo pacman -S openblas lapack cblas python-numpy  # BLAS from OpenBLAS, LAPACK from netlib
time python -c "import numpy as np; x=np.random.random((2000, 2000)); np.dot(x, x.T)"
# about 0.3 second on my system, multiple threads
sudo pacman -S openblas-lapack python-numpy  # BLAS and LAPACK from OpenBLAS
time python -c "import numpy as np; x=np.random.random((2000, 2000)); np.dot(x, x.T)"
# about 0.3 second on my system, multiple threads

I suggest to remove this package to avoid further confusion (and aur/python-scipy-openblas).

masca commented on 2019-11-27 17:47

@xia0er. I get this issue while I try to re-install (doing a clean build).

Edit: Solved after re-updating openblas-lapack!

xia0er commented on 2019-11-27 17:17

@masca, re-installing python-numpy-openblas should resolve your issue.