Re: [Numpy-discussion] NumPy 1.11.0b3 released.
On Mon, Feb 15, 2016 at 11:05 PM, Charles R Harris < charlesr.harris@gmail.com> wrote:
We have a newer version of essentially same function a second time that uses squeeze and that seems to work fine. Just to understand Why does this depend on the numpy version? I would have understood that this always failed, but this code worked for several years. https://github.com/statsmodels/statsmodels/issues/2817 Josef
On Mon, Feb 15, 2016 at 9:15 PM, <josef.pktd@gmail.com> wrote:
It's part of the indexing cleanup. In [2]: list(range(5))[np.array([0])] /home/charris/.local/bin/ipython:1: VisibleDeprecationWarning: converting an array with ndim > 0 to an index will result in an error in the future #!/usr/bin/python Out[2]: 0 The use of multidimensional arrays as indexes is likely a coding error. Or so we hope... Chuck
On Mon, Feb 15, 2016 at 11:31 PM, Charles R Harris < charlesr.harris@gmail.com> wrote:
Thanks for the explanation Or, it forces everyone to watch out for the color of the ducks :) It's just a number, whether it's python scalar, numpy scalar, 1D or 2D. And once we squeeze, we cannot iterate over it anymore. This looks like the last problem with have in statsmodels master. Part of the reason that 0.10 hurt quite a bit is that we are using in statsmodels some of the grey zones so we don't have to commit to a specific usage. Even if a user or developer tries a "weird" case, it works for most of the results, but breaks in some unknown places. (In the current case a cryptic exception would be raised if the user has two constant columns in the regression. Which is fine for some usecases but not for every result.) Josef
On Di, 2016-02-16 at 00:13 -0500, josef.pktd@gmail.com wrote:
On Tue, Feb 16, 2016 at 12:09 AM, <josef.pktd@gmail.com> wrote:
<skip>
The reason for this part is that `arr[np.array([1])]` is very different from `arr[np.array(1)]`. For `list[np.array([1])]` if you allow `operator.index(np.array([1]))` you will not get equivalent results for lists and arrays. The normal array result cannot work for lists. We had open bug reports about it. Of course I dislike it in any case ;), but that is the reasoning behind being a bit more restrictive for `__index__`. - Sebastian
On Mon, Feb 15, 2016 at 11:05 PM, Charles R Harris < charlesr.harris@gmail.com> wrote:
We have a newer version of essentially same function a second time that uses squeeze and that seems to work fine. Just to understand Why does this depend on the numpy version? I would have understood that this always failed, but this code worked for several years. https://github.com/statsmodels/statsmodels/issues/2817 Josef
On Mon, Feb 15, 2016 at 9:15 PM, <josef.pktd@gmail.com> wrote:
It's part of the indexing cleanup. In [2]: list(range(5))[np.array([0])] /home/charris/.local/bin/ipython:1: VisibleDeprecationWarning: converting an array with ndim > 0 to an index will result in an error in the future #!/usr/bin/python Out[2]: 0 The use of multidimensional arrays as indexes is likely a coding error. Or so we hope... Chuck
On Mon, Feb 15, 2016 at 11:31 PM, Charles R Harris < charlesr.harris@gmail.com> wrote:
Thanks for the explanation Or, it forces everyone to watch out for the color of the ducks :) It's just a number, whether it's python scalar, numpy scalar, 1D or 2D. And once we squeeze, we cannot iterate over it anymore. This looks like the last problem with have in statsmodels master. Part of the reason that 0.10 hurt quite a bit is that we are using in statsmodels some of the grey zones so we don't have to commit to a specific usage. Even if a user or developer tries a "weird" case, it works for most of the results, but breaks in some unknown places. (In the current case a cryptic exception would be raised if the user has two constant columns in the regression. Which is fine for some usecases but not for every result.) Josef
On Di, 2016-02-16 at 00:13 -0500, josef.pktd@gmail.com wrote:
On Tue, Feb 16, 2016 at 12:09 AM, <josef.pktd@gmail.com> wrote:
<skip>
The reason for this part is that `arr[np.array([1])]` is very different from `arr[np.array(1)]`. For `list[np.array([1])]` if you allow `operator.index(np.array([1]))` you will not get equivalent results for lists and arrays. The normal array result cannot work for lists. We had open bug reports about it. Of course I dislike it in any case ;), but that is the reasoning behind being a bit more restrictive for `__index__`. - Sebastian
participants (3)
-
Charles R Harris -
josef.pktd＠gmail.com -
Sebastian Berg