#20507: Slight annoyance wrt Numpy and ATLAS
---------------------------------+-------------------
Reporter: embray | Owner:
Type: defect | Status: new
Priority: minor | Milestone:
Component: PLEASE CHANGE | Resolution:
Keywords: | Merged in:
Authors: | Reviewers:
Report Upstream: N/A | Work issues:
Branch: | Commit:
Dependencies: | Stopgaps:
---------------------------------+-------------------
Comment (by embray):
Maybe I can try to be more specific. Indeed there are two issues here.
The first is pretty far removed from this issue but not "orthogonal"
either.
On the pkg-config files I think it would be good to emulate Debian's work
on this. For each BLAS implementation (and LAPACK) it installs a .pc file
''specific'' to that implementation. For example "blas-atlas.pc". (It
also makes good distinction between `Libs` and `Libs.private` in those
files--for example `-latlas` is only needed in `Libs.private`). The
libraries themselves are installed in `${prefix}/lib/atlas-base` (roughly
speaking). There under `${prefix}/lib` and `${prefix}/lib/pkgconfig`
there are generic symlinkss for `libblas.so` and `blas.pc` respectively.
The Debian alternatives system is used to manage which implementation
those symlinks point to. Point being that it's clear on inspection which
implementation is being used at any given time, and the library name and
version can also be used at build time for provenance purposes.
Sage doesn't have anything quite like Debian alternatives that I'm aware
of. But it could, at least for the specific case of linear algebra
libraries, and I think that would be a little nicer than the current
situation where installing ATLAS just (partially) clobbers OpenBLAS and
vice-versa. For example up above fbissey suggested using `configure` to
provide the BLAS we want to use. Right now the only supported values are
"atlas" or "openblas" but that's fine. Those spkgs can also be
responsible for deciding whether to build a copy for Sage or use the
user's system installation, as the ATLAS spkg currently does (but not
OpenBLAS from the look of it). Selecting one of these at configure time
would set a make variable called `$(BLAS)` (for example) that points to
the appropriate spkg.
A generic meta-package called simply "blas" can be used as a dependencies
of other packages that currently explicitly depend on "atlas" (unless some
package ''specifically'' requires ATLAS). The only (?) dependency of the
"blas" metapackage is `$(BLAS)`. Installing the "blas" metapackage can
also handle the `update-alternatives` like functionality of moving
symlinks around depending on `$(BLAS)`.
Anyways that's my current thinking on the subject. Getting back to Numpy
''specifically'' (and scipy), if there is a `$SAGE_BLAS`-like variable
available when its `spkg-install` is run we don't have to set all of
Numpy's `BLAS`-related environment variables to `None`. Just all except
the one we have explicitly selected to build Sage with. Then it is
unnecessary as far as I can tell to completely hobble Numpy's auto-
detection. It is guiding the auto-detection to pick exactly the
implementation you want and nothing more, and it can at least accurately
report what BLAS it was configured with (which it currently does not in
Sage, and that's what was confusing to me in the first place).
I'll grant you that currently there are hardly any places where this
matters practically (there is one place in !SciPy that it does and I'm not
sure it's that significant). That's why I marked this as "minor". It
just struck me as unnecessarily limited, and an indication of an area
where improvement could still be used.
--
Ticket URL: <http://trac.sagemath.org/ticket/20507#comment:11>
Sage <http://www.sagemath.org>
Sage: Creating a Viable Open Source Alternative to Magma, Maple, Mathematica,
and MATLAB
--
You received this message because you are subscribed to the Google Groups
"sage-trac" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at https://groups.google.com/group/sage-trac.
For more options, visit https://groups.google.com/d/optout.
