Skip to content

BUG: type checking broken with np.sinc #21898

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
bmerry opened this issue Jul 1, 2022 · 4 comments
Closed

BUG: type checking broken with np.sinc #21898

bmerry opened this issue Jul 1, 2022 · 4 comments

Comments

@bmerry
Copy link
Contributor

bmerry commented Jul 1, 2022

Describe the issue:

There seems to be something whacky with the type annotations for np.sinc that causes mypy to later think that an array is a boolean array when clearly it is not. See the reproducing code below. This seems to have started with numpy 1.22 (presumably due to the more accuracy dtype annotations). Changing np.sinc to np.sin or np.exp makes the problem disappear, which is why I assume it is specific to sinc.

Reproduce the code example:

import numpy as np

def what_the() -> None:
    idx = np.arange(16, dtype=float)
    c = idx * np.sinc(idx)
    c /= np.sum(c)

Error message:

Error message from mypy 0.961:


show_type.py:6: error: Invalid self argument "ndarray[Any, dtype[bool_]]" to attribute function "__itruediv__" with type "Callable[[ndarray[Any, dtype[floating[_NBit1]]], Union[_SupportsArray[dtype[Union[bool_, integer[Any], floating[Any]]]], _NestedSequence[_SupportsArray[dtype[Union[bool_, integer[Any], floating[Any]]]]], bool, int, float, _NestedSequence[Union[bool, int, float]]]], ndarray[Any, dtype[floating[_NBit1]]]]"

Note the bool_ on the first line.



### NumPy/Python version information:

1.23.0 3.10.5 (main, Jun 11 2022, 16:53:24) [GCC 9.4.0]
@BvB93
Copy link
Member

BvB93 commented Jul 1, 2022

This seems to be the same issue as #20099, which in turn is causes by a mypy bug (python/mypy#11347). A pr was created for the issue upstream, but I've yet to see it merged.

@bmerry
Copy link
Contributor Author

bmerry commented Jul 1, 2022

Thanks. It does sound related, so feel free to close. I'm still a bit confused why np.sinc(udx) is inferred to return ndarray[Any, Any] while np.sin(idx) is inferred to return ndarray[Any, dtype[Any]]; presumably it's because sinc is (for whatever reason) not a ufunc.

This also seems to be partly caused by dtype=float not being treated the same as dtype=np.float64; if I use the latter then the problem disappears. That sounds like a separate issue though.

@BvB93
Copy link
Member

BvB93 commented Jul 1, 2022

This also seems to be partly caused by dtype=float not being treated the same as dtype=np.float64; if I use the latter then the problem disappears. That sounds like a separate issue though.

Yeah, #19252 goes into it it more details, but the gist of the problem is that there is no convenient way of mapping float to a np.float64 (or a np.generic subtype in general) with the currently available typing tools...

@BvB93 BvB93 closed this as not planned Won't fix, can't repro, duplicate, stale Jul 1, 2022
@bmerry
Copy link
Contributor Author

bmerry commented Jul 1, 2022

Yeah, #19252 goes into it it more details, but the gist of the problem is that there is no convenient way of mapping float to a np.float64 (or a np.generic subtype in general) with the currently available typing tools...

Ah, I might have been too quick to open #21900 then. Feel free to close it as duplicate.

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

No branches or pull requests

2 participants