Skip to content

BUG: Prevent power(uint64, int64) casting to float - #8853

Closed
eric-wieser wants to merge 1 commit into
numpy:mainfrom
eric-wieser:power-mixed-sign
Closed

BUG: Prevent power(uint64, int64) casting to float#8853
eric-wieser wants to merge 1 commit into
numpy:mainfrom
eric-wieser:power-mixed-sign

Conversation

@eric-wieser

@eric-wieser eric-wieser commented Mar 27, 2017

Copy link
Copy Markdown
Member

Partials resolves #8809

Previously, the signatures were:

  • power(int, int) -> int
  • power(uint, uint) -> uint

So when we pass a mixture of int and uint, we find a common type t = common(int, uint), and invoke power(t, t) -> t.
This is bad, because common(int64, uint64) is float64

This PR defines:

  • power(int, uint) -> int
    same as power(int, int), without an error check
  • power(uint, int) -> uint:
    same as power(uint, uint), with an error check

Obviously, there is a cost associated with reducing the size of the output type - overflows happen sooner.

But what we have right now is inconsistent - from a mathematical perspective power(uint, int) has a strictly smaller range of values that can be produced than power(uint, uint) - so why do we allocate a larger output type for it?

Partials resolves numpy#8809

Previously, the signatures were:
* power(int, int) -> int
* power(uint, uint) -> uint.

Since we forbid the second argument from being negative, we can also define
* power(int, uint) -> int: same as power(int, int), without an error check
* power(uint, int) -> uint: same as power(uint, uint), with an error check

If we do not define these, then the signature used is:
* t = common(int, uint); power(t, t) -> t:

This is bad, because common(int64, uint64) is float
@homu

homu commented Apr 29, 2017

Copy link
Copy Markdown
Contributor

☔ The latest upstream changes (presumably #9015) made this pull request unmergeable. Please resolve the merge conflicts.

@charris

charris commented Oct 1, 2017

Copy link
Copy Markdown
Member

This makes sense, probably need a list posting on account of the behavior change. Also needs a rebase.

@charris

charris commented Oct 1, 2017

Copy link
Copy Markdown
Member

Looks like the release note needs to be moved to 1.14.0-notes

@eric-wieser

Copy link
Copy Markdown
Member Author

There's also the question of whether we should make this a wider-sweeping change for all int/uint arithmetic.

@mattip

mattip commented Apr 14, 2019

Copy link
Copy Markdown
Member

This needs a freshening-up, and the release note needs to move forward. I think the example should go to the power documentation as well. Since we are changing output type, does this need to hit the mailing list?

Base automatically changed from master to main March 4, 2021 02:03
@charris

charris commented Apr 22, 2021

Copy link
Copy Markdown
Member

@eric-wieser Needs rebase.

@charris charris added the 52 - Inactive Pending author response label Apr 6, 2022
@charris charris closed this Apr 6, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

BUG: Inconsistent behaviour of return type of int64.__pow__

4 participants