8000 Should can_cast report true in safe mode for long->float? · Issue #13733 · numpy/numpy · GitHub
[go: up one dir, main page]
Skip to content

Should can_cast report true in safe mode for long->float? #13733

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.

Sign up for GitHub

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

Jump to bottom
Open
dcolascione opened this issue Jun 7, 2019 · 2 comments
Open

Should can_cast report true in safe mode for long->float? #13733

dcolascione opened this issue Jun 7, 2019 · 2 comments

Comments

@dcolascione
Copy link

In [45]: np.can_cast(np.int64, np.float64, casting="safe")
Out[45]: True

Is that right? Not every int64 can be represented a a float64.
@dcolascione dcolascione mentioned this issue Jun 7, 2019
Closed
@seberg
Copy link
Member
seberg commented Jun 7, 2019 •
edited
Loading

Maybe to add at least the issue with this/where it comes from. The problem is that not that int64 should be categorized as able to cast safely to float64. I do not think anyone ever thought that is a useful way to do it. However, what was probably desired is that:

np.arange(10, dtype=np.int64) + np.ones(10, np.float64)  # just to be clear, both are default types usually

will not error out and instead be able to give a reasonable (floating point) result.

So, the reason for this was probably promotion rather than casting. Now of course, that maybe could be solved in a different way (e.g. as much as I would like to disregard it fully, by the same_kind casting rule).

@ivirshup
Copy link
Contributor

Just noticed this myself. I get that this is a reasonable trade off for promotion, but it's inconsistent with: np.can_cast(np.int32, np.float32, casting="safe") is False.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@seberg @dcolascione @ivirshup
0