summaryrefslogtreecommitdiff
path: root/doc/release/upcoming_changes/16200.compatibility.rst
blob: 2bbdd883ed4863dfde0e685bf9dad0b1c19da35a (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
NumPy Scalars are cast when assigned to arrays
----------------------------------------------

When creating or assigning to arrays, in all relevant cases NumPy
scalars will now be cast identically to NumPy arrays.  In particular
this changes the behaviour in some cases which previously raised an
error::

    np.array([np.float64(np.nan)], dtype=np.int64)

will succeed and return an undefined result (usually the smallest possible
integer).  This also affects assignments::

    arr[0] = np.float64(np.nan)

At this time, NumPy retains the behaviour for::

    np.array(np.float64(np.nan), dtype=np.int64)

The above changes do not affect Python scalars:

    np.array([float("NaN")], dtype=np.int64)

remains unaffected (``np.nan`` is a Python ``float``, not a NumPy one).
Unlike signed integers, unsigned integers do not retain this special case,
since they always behaved more like casting.
The following code stops raising an error::

    np.array([np.float64(np.nan)], dtype=np.uint64)

To avoid backward compatibility issues, at this time assignment from
``datetime64`` scalar to strings of too short length remains supported.
This means that ``np.asarray(np.datetime64("2020-10-10"), dtype="S5")``
succeeds now, when it failed before.  In the long term this may be
deprecated or the unsafe cast may be allowed generally to make assignment
of arrays and scalars behave consistently.


Array coercion changes when Strings and other types are mixed
-------------------------------------------------------------

When stringss and other types are mixed, such as::

    np.array(["string", np.float64(3.)], dtype="S")

The results will change, which may lead to string dtypes with longer strings
in some cases.  In particularly, if ``dtype="S"`` is not provided any numerical
value will lead to a string results long enough to hold all possible numerical
values. (e.g. "S32" for floats).  Note that you should always provide
``dtype="S"`` when converting non-strings to strings.

If ``dtype="S"`` is provided the results will be largely identical to before,
but NumPy scalars (not a Python float like ``1.0``), will still enforce
a uniform string length::

    np.array([np.float64(3.)], dtype="S")  # gives "S32"
    np.array([3.0], dtype="S")  # gives "S3"

while previously the first version gave the same result as the second.


Array coercion restructure
--------------------------

Array coercion has been restructured.  In general, this should not affect
users.  In extremely rare corner cases where array-likes are nested::

    np.array([array_like1])

things will now be more consistent with::

    np.array([np.array(array_like1)])

which could potentially change output subtly for badly defined array-likes.
We are not aware of any such case where the results were not clearly
incorrect previously.