Mailman 3 July 2016 - NumPy-Discussion

StackOverflow documentation
by Jaime Fernández del Río 21 Jul '16

21 Jul '16

StackOverflow now also has documentation, and there already is a NumPy tag: http://stackoverflow.com/documentation/numpy Not sure what, if anything, do we want to do with this, nor how to handle not having to different sources with the same information. Any thoughts? Jaime -- (\__/) ( O.o) ( > <) Este es Conejo. Copia a Conejo en tu firma y ayúdale en sus planes de dominación mundial.

5 4

Adding covariance matrix of fitted parameters to fit methods of numpy.polynomial
by Tom Bird 21 Jul '16

21 Jul '16

See issue #7780: https://github.com/numpy/numpy/issues/7780 Would be good if the numpy.polynomial fit methods (e.g. numpy.polynomial.legendre.Legendre.fit) could return the covariance matrix of the fitted parameters, in the same way as numpy.polyfit. Let me know if there are any suggestions/concerns. Otherwise I’m happy to add the code and update the docs. Tom

1 0

Python 3 dict support (issue #5718)
by Hannah 21 Jul '16

21 Jul '16

Hi, I started venturing down the rabbit hole of trying to write a patch to add support for numpy to convert python 3 dictionary keys (collections.abc.ViewMapping objects), which is open issue #5718 and am having trouble orienting myself. I'm unclear as to where the python entry point into array is (basically, what function np.array drops into and if this is in Python or C) and where/what language (fine with writing either) a patch that supports MappingViews would go. Any help getting oriented would be much appreciated. The reasoning for the patch is s that dicts are one of the most common Python datatypes and this specifically is because of an upstream issue of wanting dict support in matplotlib. Thanks, Hannah

4 8

Numpy set_printoptions, silent failure, bug?
by John Ladasky 19 Jul '16

19 Jul '16

Hi there, I've been using Numpy for several years and appreciate it very much. The following minimal code has been tried on Python 3.4 and 3.5, with Numpy 1.8 and Numpy 1.11, respectively. I want to temporarily change the way that a Numpy array is printed, then change it back. import numpy as np a = np.random.random((4,3)) print(a, "\n") opt = np.get_printoptions() np.set_printoptions(precision = 3, suppress = True) print(a, "\n") np.set_printoptions(opt) print(a, "\n\nDone.\n") Here is the traceback: Traceback (most recent call last): File "set_printoptions test.py", line 11, in <module> print(a, "\n\nDone.\n") File "/usr/lib/python3/dist-packages/numpy/core/numeric.py", line 1615, in array_str return array2string(a, max_line_width, precision, suppress_small, ' ', "", str) File "/usr/lib/python3/dist-packages/numpy/core/arrayprint.py", line 454, in array2string separator, prefix, formatter=formatter) File "/usr/lib/python3/dist-packages/numpy/core/arrayprint.py", line 328, in _array2string _summaryEdgeItems, summary_insert)[:-1] File "/usr/lib/python3/dist-packages/numpy/core/arrayprint.py", line 523, in _formatArray summary_insert) File "/usr/lib/python3/dist-packages/numpy/core/arrayprint.py", line 497, in _formatArray word = format_function(a[-i]) + separator File "/usr/lib/python3/dist-packages/numpy/core/arrayprint.py", line 616, in __call__ s = self.format % x AttributeError: 'FloatFormat' object has no attribute 'format' It took me a while to discover the bug, on the second to last line. That line should read: np.set_printoptions(**opt) This unpacks the dictionary, opt, which was retrieved earlier in the program with the call to get_printoptions. I am wondering why set_printoptions would accept the dictionary as a single argument. Shouldn't that raise a TypeError or something? The AttributeError that is raised the next time that one attempts to print a numpy array is remote from the problem, and thus rather uninformative, which is why I did not immediately diagnose my error. Should this be considered a Numpy bug, or is there some reason that set_printoptions would legitimately need to accept a dictionary as a single argument? -- *John J. Ladasky Jr., Ph.D.* *Research Scientist* *International Technological University* *2711 N. First St, San Jose, CA 95134 USA*

3 4

runtests.py fails f2py test
by Matti Picus 19 Jul '16

19 Jul '16

Am I missing something simple? I - install git, subversion, gcc, gfortran (Ubuntu 16.04) - create a clean python2 virtual env (no numpy) - activate it - git clone numpy - cd into it - python runtests.py - wait And it fails tests because it cannot find f2py. Then I - python setup.py install # to install numpy - cd numpy/f2py - python setup.py build And setup fails: F2PY Version 2 Traceback (most recent call last): File "setup.py", line 117, in <module> **config) TypeError: setup() got multiple values for keyword argument 'version' Can someone give me a one-line hint what I am doing wrong? Matti

2 1

Performance issue in covariance function in Numpy 1.9 and later
by Ecem sogancıoglu 19 Jul '16

19 Jul '16

Hello All, there seems to be a performance issue with the covariance function in numpy 1.9 and later. Code example: *np.cov(np.random.randn(700,37000))* In numpy 1.8, this line of code requires 4.5755 seconds. In numpy 1.9 and later, the same line of code requires more than 30.3709 s execution time. Has anyone else observed this problem and is there a known bugfix?

2 1

Building numpy with ATLAS
by Shitikanth Kashyap 19 Jul '16

19 Jul '16

Hey Everyone, I am trying to build numpy-1.11.1 with ATLAS libraries. The build completes successfully, and I am able to use numpy, but there seems to be some problem with my config because numpy only ever uses one core, even when multiplying 5000x5000 matrices with numpy.dot. My site.cfg is: [default] library_dirs = /u3/s4kashya/.local/atlas3.11/lib:/u3/s4kashya/.local/lib:/usr/local/lib:/usr/lib include_dirs = /u3/s4kashya/.local/atlas3.11/include:/u3/s4kashya/.local/include:/usr/local/include:/usr/include [atlas] libraries = ptlapack, ptf77blas, ptcblas, atlas library_dirs = /u3/s4kashya/.local/atlas3.11/lib include_dirs = /u3/s4kashya/.local/atlas3.11/include Output from numpy.__config__.show(): atlas_3_10_blas_threads_info: libraries = ['tatlas', 'ptlapack', 'ptf77blas', 'ptcblas', 'atlas'] library_dirs = ['/u3/s4kashya/.local/atlas3.11/lib'] define_macros = [('HAVE_CBLAS', None), ('NO_ATLAS_INFO', -1)] language = c include_dirs = ['/u3/s4kashya/.local/atlas3.11/include'] lapack_opt_info: libraries = ['tatlas', 'tatlas', 'tatlas', 'ptlapack', 'ptf77blas', 'ptcblas', 'atlas'] library_dirs = ['/u3/s4kashya/.local/atlas3.11/lib'] define_macros = [('NO_ATLAS_INFO', -1)] language = f77 include_dirs = ['/u3/s4kashya/.local/atlas3.11/include'] blas_opt_info: libraries = ['tatlas', 'ptlapack', 'ptf77blas', 'ptcblas', 'atlas'] library_dirs = ['/u3/s4kashya/.local/atlas3.11/lib'] define_macros = [('HAVE_CBLAS', None), ('NO_ATLAS_INFO', -1)] language = c include_dirs = ['/u3/s4kashya/.local/atlas3.11/include'] openblas_info: NOT AVAILABLE openblas_lapack_info: NOT AVAILABLE atlas_3_10_threads_info: libraries = ['tatlas', 'tatlas', 'tatlas', 'ptlapack', 'ptf77blas', 'ptcblas', 'atlas'] library_dirs = ['/u3/s4kashya/.local/atlas3.11/lib'] define_macros = [('NO_ATLAS_INFO', -1)] language = f77 include_dirs = ['/u3/s4kashya/.local/atlas3.11/include'] lapack_mkl_info: NOT AVAILABLE blas_mkl_info: NOT AVAILABLE mkl_info: NOT AVAILABLE Any ideas what could be going wrong? Thanks, Shitikanth

1 1

isnan() equivalent for np.NaT?
by Scott Sanderson 18 Jul '16

18 Jul '16

Hi All, I'm working on upgrading Zipline (github.com/quantopian/zipline) to the latest numpy, and I'm getting a FutureWarnings about the upcoming change in the behavior of comparisons on np.NaT. I'd like to be able to do checks for NaT in a way that's forwards-compatible, but I couldn't find a function analogous to `np.isnan` for NaT. Am I missing something that already exists? If not, is there interest in such a function? I'd like to be able to pre-emptively fix the warnings in Zipline so that we're ready when the change actually happens, but it doesn't seem like the necessary tools are available right now. -Scott

3 2

deterministic, reproducible matmul / __matmult_
by Jason Newton 18 Jul '16

18 Jul '16

Hello I'm a long time user of numpy - but an issue I've had with it is making sure I can reproduce the results of a floating point matrix multiplication in other languages/modules (like c or GPU) in another, or across installations. I take great pains in doing this type of work because it allows me to both prototype with python/numpy and to also in a fairly strong/useful capacity, use it as a strict reference implementation. For me - small differences accumulate such that allclose type thinking starts failing in a few iterations of algorithms, things diverge. I've had success with einsum before for some cases (by chance) where no difference was ever observed between it and Eigen (C++), but I'm not sure if I should use this any longer. The new @ operator is very tempting to use too, in prototyping. Does the ML have any ideas on how one could get a matmul that will not allow any funny business on the evaluation of the products? Funny business here is something like changing the evaluation order additions of terms. I want strict IEEE 754 compliance - no 80 bit registers, and perhaps control of the rounding mode, no unsafe math optimizations. I'm definitely willing to sacrifice performance (esp multi threaded based enhancements which already cause problems in reduction ordering) in order to get these guarantees. I was looking around and found a few BLAS's that might be worth a mention, comments on these would also be welcome: http://bebop.cs.berkeley.edu/reproblas/ https://exblas.lip6.fr/ -Jason

2 2

Numpy Jenkin's Traub?
by Ryan J. Kinnear 17 Jul '16

17 Jul '16

Dear list, I'm working on implementing an ARMA(p, q) modeling method in Python. The particular method is described in section 4.7.1 of Statistical Digital Signal Processing and Modeling by Hayes. The upshot is that I need to calculate the roots of a polynomial. I've learned that this is a numerically ill conditioned problem, and have found many cases where np.roots produces roots that are clearly spurious. This is causing me a lot of issues. I have done some further searching and learned of the "Jenkins-Traub" algorithm for root finding, which seems to be considered the most robust method. I found a Python implementation of this method here (https://github.com/vrdabomb5717/jenkins_traub), and it is certainly much more robust than np.roots. Are there reasons for Jenkins-Traub not being implemented as part of Numpy? It is built into Scilab (https://help.scilab.org/docs/6.0.0/en_US/roots.html) Is anyone working on getting it into Numpy? -RJK

2 1