Hi Nadav,
On Sun, Feb 7, 2016 at 11:13 PM, Nathaniel Smith wrote:
> (This is not relevant to the main topic of the thread, but FYI I think the
> recarray issues are fixed in 1.10.4.)
>
> On Feb 7, 2016 11:10 PM, "Nadav Horesh" wrote:
>>
>> I have atlas-lapack-base installed via pacman (required
(This is not relevant to the main topic of the thread, but FYI I think the
recarray issues are fixed in 1.10.4.)
On Feb 7, 2016 11:10 PM, "Nadav Horesh" wrote:
> I have atlas-lapack-base installed via pacman (required by sagemath).
> Since the numpy installation insisted on openblas on /usr/local
I have atlas-lapack-base installed via pacman (required by sagemath). Since the
numpy installation insisted on openblas on /usr/local, I got the openblas
source-code and installed it on /usr/local.
BTW, I use 1.11b rather then 1.10.x since the 1.10 is very slow in handling
recarrays. For the te
On Sat, Feb 6, 2016 at 9:28 PM, Nadav Horesh wrote:
> Test platform: python 3.4.1 on archlinux x86_64
>
> scipy test: OK
>
> OK (KNOWNFAIL=97, SKIP=1626)
>
>
> numpy tests: Failed on long double and int128 tests, and got one error:
Could you post the complete output from the test suite somewhere?
On Sun, Feb 7, 2016 at 10:09 PM, Nadav Horesh wrote:
> Thank you fo reminding me, it is OK now:
> $ python -c 'import numpy; print(numpy.__config__.show())'
>
> lapack_opt_info:
> library_dirs = ['/usr/local/lib']
> language = c
> libraries = ['openblas']
> define_macros = [('HAVE_
Thank you fo reminding me, it is OK now:
$ python -c 'import numpy; print(numpy.__config__.show())'
lapack_opt_info:
library_dirs = ['/usr/local/lib']
language = c
libraries = ['openblas']
define_macros = [('HAVE_CBLAS', None)]
blas_mkl_info:
NOT AVAILABLE
openblas_info:
lib
On Sun, Feb 7, 2016 at 4:39 PM, Nils Becker wrote:
> Hi all,
>
> I wanted to know if there is any sane way to build numpy while linking to a
> different implementation of libm?
> A drop-in replacement for libm (e.g. openlibm) should in principle work, I
> guess, but I did not manage to actually ma
Hi all,
I wanted to know if there is any sane way to build numpy while linking to a
different implementation of libm?
A drop-in replacement for libm (e.g. openlibm) should in principle work, I
guess, but I did not manage to actually make it work. As far as I
understand the build code, setting MATH
On Feb 7, 2016 15:27, "Charles R Harris" wrote:
>
>
>
> On Sun, Feb 7, 2016 at 2:16 PM, Nathaniel Smith wrote:
>>
>> On Sun, Feb 7, 2016 at 9:49 AM, Charles R Harris
>> wrote:
>> >
>> >
>> > On Sun, Feb 7, 2016 at 3:40 AM, Nathaniel Smith wrote:
>> >>
>> >> On Feb 6, 2016 12:27 PM, "Matthew Bre
Hi,
On Sun, Feb 7, 2016 at 2:06 AM, Nadav Horesh wrote:
> The reult tests of numpy 1.10.4 installed from source:
>
> OK (KNOWNFAIL=4, SKIP=6)
>
>
> I think I use openblas, as it is installed instead the normal blas/cblas.
Thanks again for the further tests.
What do you get for:
python -c 'impo
That makes sense. I could either send a signal to the child process
letting it know to re-instantiate the numpy array using the same (but now
resized) buffer, or I could have it check to see if the buffer has been
resized when it might need it and re-instantiate then. That's actually not
too bad.
On Feb 6, 2016 12:27 PM, "Matthew Brett" wrote:
>
> Hi,
>
> As some of you may have seen, Robert McGibbon and Nathaniel have just
> guided a PEP for multi-distribution Linux wheels past the approval
> process over on distutils-sig:
>
> https://www.python.org/dev/peps/pep-0513/
>
> The PEP includes
The reult tests of numpy 1.10.4 installed from source:
OK (KNOWNFAIL=4, SKIP=6)
I think I use openblas, as it is installed instead the normal blas/cblas.
Nadav,
From: NumPy-Discussion on behalf of Nadav
Horesh
Sent: 07 February 2016 07:28
To: Discus
13 matches
Mail list logo
