[Numpy-discussion] Python 3 dict support (issue #5718)
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 ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org https://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Numpy set_printoptions, silent failure, bug?
Thank you Juan, I've just joined GitHub and I've submitted the description of the bug. On Tue, Jul 19, 2016 at 2:55 PM, Juan Nunez-Iglesias wrote: > https://github.com/numpy/numpy/issues > > > From: John Ladasky > Reply: Discussion of Numerical Python > > Date: 20 July 2016 at 7:49:10 AM > To: Discussion of Numerical Python > > Subject: Re: [Numpy-discussion] Numpy set_printoptions, silent failure, > bug? > > Hi Robert, >> >> Thanks for your reply. If no one disagrees with you or with me that this >> is a Numpy bug, I would appreciate being directed to the appropriate page >> to submit a bug-fix request. >> >> >> On Tue, Jul 19, 2016 at 2:43 PM, Robert Kern >> wrote: >> >>> On Tue, Jul 19, 2016 at 10:41 PM, John Ladasky wrote: >>> >>> > 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? >>> >>> There is no such reason. One could certainly add more validation to the >>> arguments to np.set_printoptions(). >>> >>> -- >>> Robert Kern >>> >>> ___ >>> NumPy-Discussion mailing list >>> NumPy-Discussion@scipy.org >>> https://mail.scipy.org/mailman/listinfo/numpy-discussion >>> >>> >> >> >> -- >> *John J. Ladasky Jr., Ph.D.* >> *Research Scientist* >> *International Technological University* >> *2711 N. First St, San Jose, CA 95134 USA* >> ___ >> NumPy-Discussion mailing list >> NumPy-Discussion@scipy.org >> https://mail.scipy.org/mailman/listinfo/numpy-discussion >> > > ___ > NumPy-Discussion mailing list > NumPy-Discussion@scipy.org > https://mail.scipy.org/mailman/listinfo/numpy-discussion > > -- *John J. Ladasky Jr., Ph.D.* *Research Scientist* *International Technological University* *2711 N. First St, San Jose, CA 95134 USA* ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org https://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Numpy set_printoptions, silent failure, bug?
https://github.com/numpy/numpy/issues From: John Ladasky Reply: Discussion of Numerical Python Date: 20 July 2016 at 7:49:10 AM To: Discussion of Numerical Python Subject: Re: [Numpy-discussion] Numpy set_printoptions, silent failure, bug? Hi Robert, > > Thanks for your reply. If no one disagrees with you or with me that this > is a Numpy bug, I would appreciate being directed to the appropriate page > to submit a bug-fix request. > > > On Tue, Jul 19, 2016 at 2:43 PM, Robert Kern > wrote: > >> On Tue, Jul 19, 2016 at 10:41 PM, John Ladasky wrote: >> >> > 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? >> >> There is no such reason. One could certainly add more validation to the >> arguments to np.set_printoptions(). >> >> -- >> Robert Kern >> >> ___ >> NumPy-Discussion mailing list >> NumPy-Discussion@scipy.org >> https://mail.scipy.org/mailman/listinfo/numpy-discussion >> >> > > > -- > *John J. Ladasky Jr., Ph.D.* > *Research Scientist* > *International Technological University* > *2711 N. First St, San Jose, CA 95134 USA* > ___ > NumPy-Discussion mailing list > NumPy-Discussion@scipy.org > https://mail.scipy.org/mailman/listinfo/numpy-discussion > ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org https://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Numpy set_printoptions, silent failure, bug?
Hi Robert, Thanks for your reply. If no one disagrees with you or with me that this is a Numpy bug, I would appreciate being directed to the appropriate page to submit a bug-fix request. On Tue, Jul 19, 2016 at 2:43 PM, Robert Kern wrote: > On Tue, Jul 19, 2016 at 10:41 PM, John Ladasky wrote: > > > 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? > > There is no such reason. One could certainly add more validation to the > arguments to np.set_printoptions(). > > -- > Robert Kern > > ___ > NumPy-Discussion mailing list > NumPy-Discussion@scipy.org > https://mail.scipy.org/mailman/listinfo/numpy-discussion > > -- *John J. Ladasky Jr., Ph.D.* *Research Scientist* *International Technological University* *2711 N. First St, San Jose, CA 95134 USA* ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org https://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Numpy set_printoptions, silent failure, bug?
On Tue, Jul 19, 2016 at 10:41 PM, John Ladasky wrote: > 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? There is no such reason. One could certainly add more validation to the arguments to np.set_printoptions(). -- Robert Kern ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org https://mail.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] Numpy set_printoptions, silent failure, bug?
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 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* ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org https://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] runtests.py fails f2py test
On Fri, Jul 15, 2016 at 3:50 PM, Matti Picus wrote: > 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. > I can confirm that runtests.py doesn't install f2py into the virtualenv bin directory. This issue is hard to run into though, because if you've ever installed numpy on your system before (outside a virtualenv), then you probably already have f2py on your PATH (it's at .local/bin/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 > **config) > TypeError: setup() got multiple values for keyword argument 'version' > > f2py isn't supposed to be installed standalone, I'm not surprised that that doesn't work. Ralf > Can someone give me a one-line hint what I am doing wrong? > Matti > ___ > NumPy-Discussion mailing list > NumPy-Discussion@scipy.org > https://mail.scipy.org/mailman/listinfo/numpy-discussion > ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org https://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Performance issue in covariance function in Numpy 1.9 and later
On Tue, Jul 19, 2016 at 3:53 PM, Ecem sogancıoglu wrote: > 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. > Hi Ecem, can you make sure to use the exact same random array as input to np.cov when testing this? Also timing just the function call you're interested in would be good; the creating of your 2-D array takes longer than the np.cov call: In [5]: np.random.seed(1234) In [6]: x = np.random.randn(700,37000) In [7]: %timeit np.cov(x) 1 loops, best of 3: 572 ms per loop In [8]: %timeit np.random.randn(700, 37000) 1 loops, best of 3: 1.26 s per loop Cheers, Ralf > Has anyone else observed this problem and is there a known bugfix? > > > ___ > NumPy-Discussion mailing list > NumPy-Discussion@scipy.org > https://mail.scipy.org/mailman/listinfo/numpy-discussion > > ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org https://mail.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] Performance issue in covariance function in Numpy 1.9 and later
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? ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org https://mail.scipy.org/mailman/listinfo/numpy-discussion