You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Deprecate/remove silent truncation on assignment of floats into an integer array #7730
The behaviour is of course correct, a is autotyped to be an integer array, so the float is cast to an integer on assignment. This could have a warning in principle for the unsafe cast, but it is expected and has to work that way since numpy arrays are (normally) typed.
changed the title [-]Erroneous rounding upon assignment to array element[/-][+]Deprecate/remove silent truncation on assignment of floats into an integer array[/+]on Jun 17, 2016
Sounds like everyone is in favor, so I renamed the bug report. I guess concretely the desired change should follow the same path we used for in-place operations? Which IIRC was that we switched it to same_kind casting, with a deprecation period.
Yeah, would have to be a pretty long deprecation just like there. I am a little worried that the workaround with copyto or casting the right hand side is sometimes a bit annoying. But I suppose that it should be rare that a bit of explicit casting/more convolved stuff does not hurt and the error can easily tell you the solution.
I think this is an important usability issue. One of my labmates @sumeetsk wasted a month of research effort on this bug (and just before his defense too). It boiled down to
Overflow and truncation seem to be mentioned often as issues. Maybe we could have a verbose mode that would report overflow and truncation as warnings, at a cost in performance
Activity
seberg commentedon Jun 11, 2016
The behaviour is of course correct,
ais autotyped to be an integer array, so the float is cast to an integer on assignment. This could have a warning in principle for the unsafe cast, but it is expected and has to work that way since numpy arrays are (normally) typed.charris commentedon Jun 11, 2016
Note that numpy doesn't round in these cases, it truncates. @seberg I thought this was deprecated, but it doesn't seem so.
seberg commentedon Jun 11, 2016
There is only a deprecation for the in place ufuncs, maybe we should think about making this deprecate too?
charris commentedon Jun 11, 2016
@seberg Sounds like a good idea, we should raise it on the list.
njsmith commentedon Jun 13, 2016
https://mail.scipy.org/pipermail/numpy-discussion/2016-June/075679.html
[-]Erroneous rounding upon assignment to array element[/-][+]Deprecate/remove silent truncation on assignment of floats into an integer array[/+]njsmith commentedon Jun 17, 2016
Sounds like everyone is in favor, so I renamed the bug report. I guess concretely the desired change should follow the same path we used for in-place operations? Which IIRC was that we switched it to same_kind casting, with a deprecation period.
seberg commentedon Jun 18, 2016
Yeah, would have to be a pretty long deprecation just like there. I am a little worried that the workaround with copyto or casting the right hand side is sometimes a bit annoying. But I suppose that it should be rare that a bit of explicit casting/more convolved stuff does not hurt and the error can easily tell you the solution.
stsievert commentedon Dec 4, 2018
I think this is an important usability issue. One of my labmates @sumeetsk wasted a month of research effort on this bug (and just before his defense too). It boiled down to
which is unexpected. This issue is also mentioned in a textbook:
I'll try to submit a PR for this issue. This is still around in NumPy 1.14.3, and the recent release notes don't seem to mention it.
sumeetsk commentedon Dec 5, 2018
What makes this especially unexpected / counter-intuitive is that python does not behave this way.
mattip commentedon Dec 23, 2018
Overflow and truncation seem to be mentioned often as issues. Maybe we could have a
verbosemode that would report overflow and truncation as warnings, at a cost in performancestevengj commentedon Mar 24, 2022
(Note that this issue and #8733 are basically duplicates.)