Package Details: python-numpy-openblas 1.20.0-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.20.0, python3-numpy=1.20.0
Submitter: xia0er
Maintainer: xia0er
Last Packager: xia0er
Votes: 23
Popularity: 0.003442
First Submitted: 2013-11-21 20:38
Last Updated: 2021-02-03 06:26

Required by (1000)

Sources (1)

Latest Comments

1 2 3 4 5 6 ... Next › Last »

Xyne commented on 2020-12-05 18:10

Can you please add python-hypothesis to the makedepends array. It's required for the check function. Thanks!

mdeff commented on 2020-10-08 11:12

Yes a distribution-wide switch would be ideal (Arch does it for Java, and others like Debian have a generic method that they use for BLAS too).

bnavigator commented on 2020-10-05 11:49

Hi,

the mentioned ArchWiki page and an Archlinux wide switching approach would be greatly appreciated.

See also https://github.com/python-control/Slycot/issues/138#issuecomment-703573577

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?