On Wed, Mar 30, 2016 at 2:39 PM, Carl Kleffner wrote:
> I would like to see OpenBLAS support for numpy on windows. The latest
> OpenBLAS windows builds numpy support for are on
> https://bitbucket.org/carlkl/mingw-w64-for-python/downloads now. Scipy
> wheels should work regardless if numpy was bui
I would like to see OpenBLAS support for numpy on windows. The latest
OpenBLAS windows builds numpy support for are on
https://bitbucket.org/carlkl/mingw-w64-for-python/downloads now. Scipy
wheels should work regardless if numpy was build with MSVC or with mingwpy.
It is only mandantory to agree ab
If OpenBLAS is looking like the easiest to support solution, then no
objections here. (If 0.2.17 is genuinely working well, then maybe we want
to switch to it on Windows too. I know Xianyi disabled some of the
problematic kernels for us -- maybe that's enough. Mostly I just don't want
to end up in
Hi all,
This is a warning for a planned change to np.memmap in
https://github.com/numpy/numpy/pull/7406.
The return values of ufuncs and fancy slices of a memmap will now be
plain ndarrays, since those return values don't point to mem-mapped memory.
There is a possibility that if you are subclas
On Nix/NixOS we've been using OpenBLAS 0.2.14 for some time now because we
had some segmentation faults with 0.2.15 and scipy/scikitlearn. I've tested
the packages you listed, and more, with OpenBLAS 0.2.17 and encountered no
problems.
On Wed, Mar 30, 2016 at 1:32 PM, Olivier Grisel
wrote:
> The
The problem with the gfortran failures will be tackled by renaming the
vendored libgfortran.so library, see:
https://github.com/pypa/auditwheel/issues/24
This is orthogonal to the ATLAS vs OpenBLAS decision though.
--
Olivier
___
NumPy-Discussion mail
