Skip to content

BUG: Only convert 0d arrays to scalars in power - #4146

Merged
juliantaylor merged 1 commit into
numpy:masterfrom
seberg:issue-4145
Mar 1, 2014
Merged

juliantaylor merged 1 commit into
numpy:masterfrom
seberg:issue-4145

Conversation

@seberg

@seberg seberg commented Dec 26, 2013

Copy link
Copy Markdown
Member

Operations such as x**array([2]) would convert the
2 into an integer and loose the dimension information,
because the array (at this time, it is deprecated),
supports __index__ even though it is not 0-d.

This fixes it, by not trying the index machinery
when it was an array, since it is unnecessary.

Closes gh-4145

Really very simple fix. Should likely be backported.

@seberg

seberg commented Dec 26, 2013

Copy link
Copy Markdown
Member Author

It might be possible to simplify the function using other conversion functions, but this fixes the issue at hand nicely.

@WarrenWeckesser

Copy link
Copy Markdown
Member

This doesn't fix the problem:

$ python -W always
Python 2.7.6 |Anaconda 1.8.0 (64-bit)| (default, Nov 11 2013, 10:47:18) 
[GCC 4.1.2 20080704 (Red Hat 4.1.2-54)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import numpy as np
>>> np.__version__
'1.9.0.dev-7194978'
>>> x = np.array([1, 2, 3])
>>> y = np.array([[2]])
>>> x ** y
__main__:1: DeprecationWarning: converting an array with ndim > 0 to an index will result in an error in the future
array([1, 4, 9])

If I don't use -W always, I don't get the DeprecationWarning (as expected), but the shape of the result is still wrong.

This PR only works if I run python as python -W error (or use warnings.filterwarnings to do the same thing).

$ python -W error
Python 2.7.6 |Anaconda 1.8.0 (64-bit)| (default, Nov 11 2013, 10:47:18) 
[GCC 4.1.2 20080704 (Red Hat 4.1.2-54)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import numpy as np
>>> x = np.array([1, 2, 3])
>>> y = np.array([[2]])
>>> x ** y
array([[1, 4, 9]])
>>> 

@seberg

seberg commented Dec 26, 2013

Copy link
Copy Markdown
Member Author

OOps, right point, completly nonsense fix :)

@seberg

seberg commented Jan 21, 2014

Copy link
Copy Markdown
Member Author

Updated, could remove the numpy scalar branch, since we support Index, but it should not really matter either way.
EDIT: nvm about that, that would require some other handling for the float scalars.

@rgommers

Copy link
Copy Markdown
Member

Maybe a bit late for 1.8.1rc1, but this would be useful to merge and backport. Just ran into this, and it's quite annoying to avoid.

@charris

charris commented Feb 27, 2014

Copy link
Copy Markdown
Member

OK, lets give it a shot. I supose 1.8.1 will give us some testing of these fixes also.

@charris

charris commented Feb 27, 2014

Copy link
Copy Markdown
Member

Merged, thanks Sebastian.

Oops, needs a rebase now.

@seberg

seberg commented Feb 27, 2014

Copy link
Copy Markdown
Member Author

Rebased.

@WarrenWeckesser

Copy link
Copy Markdown
Member

Why does the test still need to filter warnings? The code being tested should not raise a warning. If it does, it is a bug.

@seberg

seberg commented Feb 28, 2014

Copy link
Copy Markdown
Member Author

Oops, yes, it does not do that anymore, so removed it.

Operations such as `x**array([2])` would convert the
2 into an integer and loose the dimension information,
because the array (at this time, it is deprecated),
supports `__index__` even though it is not 0-d.

This fixes it, by not trying the index machinery
when it was an array, since it is unnecessary.

Closes numpygh-4145
juliantaylor added a commit that referenced this pull request Mar 1, 2014
BUG: Only convert 0d arrays to scalars in power
@juliantaylor
juliantaylor merged commit e97601d into numpy:master Mar 1, 2014
@juliantaylor

Copy link
Copy Markdown
Contributor

merged but its a nontrivial backport, if you want it in do it quick

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

BUG: Incorrect shape of broadcast result with the exponentiation operator **.

5 participants