Skip to content

Deprecate/remove silent truncation on assignment of floats into an integer array #7730

Open

Description

@markrichardson

Ubuntu 14.04
Python 2.7.11

In [1]: import numpy as np

In [2]: np.__version__
Out[2]: '1.10.4'

In [3]: v = 4 - 0.1

In [4]: np.array([v])
Out[4]: array([ 3.9])

In [5]: a = np.array([1]); a[0] = v; a
Out[5]: array([3])

Activity

  1. seberg commented on Jun 11, 2016

    @seberg
    Member

    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.

  2. charris commented on Jun 11, 2016

    @charris
    Member

    Note that numpy doesn't round in these cases, it truncates. @seberg I thought this was deprecated, but it doesn't seem so.

  3. seberg commented on Jun 11, 2016

    @seberg
    Member

    There is only a deprecation for the in place ufuncs, maybe we should think about making this deprecate too?

  4. charris commented on Jun 11, 2016

    @charris
    Member

    @seberg Sounds like a good idea, we should raise it on the list.

  5. 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
  6. njsmith commented on Jun 17, 2016

    @njsmith
    Member

    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.

  7. seberg commented on Jun 18, 2016

    @seberg
    Member

    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.

  8. stsievert commented on Dec 4, 2018

    @stsievert

    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

    >>> a = np.array([0, 1, 2])
    >>> a[0] = 1.1
    >>> print(a)
    ... array([1, 1, 2])

    which is unexpected. This issue is also mentioned in a textbook:

    if you attempt to insert a floating-point value to an integer array, the value will be silently truncated. Don't be caught unaware by this behavior!

    — @jakevdp's Data Science Handbook, Chapter 2.2 "The Basics of NumPy Arrays"

    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.

  9. sumeetsk commented on Dec 5, 2018

    @sumeetsk

    What makes this especially unexpected / counter-intuitive is that python does not behave this way.

    image

  10. mattip commented on Dec 23, 2018

    @mattip
    Member

    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

  11. stevengj commented on Mar 24, 2022

    @stevengj

    (Note that this issue and #8733 are basically duplicates.)

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

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions