[Numpy-discussion] Python 3 dict support (issue #5718)

[Hannah]

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?

[John Ladasky]

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?

[Juan Nunez-Iglesias]

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?

[John Ladasky]

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?

[Robert Kern]

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?

[John Ladasky]

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

[Ralf Gommers]

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

[Ralf Gommers]

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

[Ecem sogancıoglu]

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