Skip to content
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

Update dependency numpy to v1.20.1 - autoclosed #14

Closed
wants to merge 1 commit into from

Conversation

renovate[bot]
Copy link

@renovate renovate bot commented Feb 22, 2021

WhiteSource Renovate

This PR contains the following updates:

Package Change Age Adoption Passing Confidence
numpy (source) ==1.19.5 -> ==1.20.1 age adoption passing confidence

Release Notes

numpy/numpy

v1.20.1

Compare Source

NumPy 1.20.1 Release Notes

NumPy 1.20.1 is a rapid bugfix release fixing several bugs and
regressions reported after the 1.20.0 release.

Highlights

  • The distutils bug that caused problems with downstream projects is
    fixed.
  • The random.shuffle regression is fixed.

Contributors

A total of 8 people contributed to this release. People with a \"+\" by
their names contributed a patch for the first time.

  • Bas van Beek
  • Charles Harris
  • Nicholas McKibben +
  • Pearu Peterson
  • Ralf Gommers
  • Sebastian Berg
  • Tyler Reddy
  • \@​Aerysv +

Pull requests merged

A total of 15 pull requests were merged for this release.

  • #​18306: MAINT: Add missing placeholder annotations
  • #​18310: BUG: Fix typo in numpy.__init__.py
  • #​18326: BUG: don\'t mutate list of fake libraries while iterating over...
  • #​18327: MAINT: gracefully shuffle memoryviews
  • #​18328: BUG: Use C linkage for random distributions
  • #​18336: CI: fix when GitHub Actions builds trigger, and allow ci skips
  • #​18337: BUG: Allow unmodified use of isclose, allclose, etc. with timedelta
  • #​18345: BUG: Allow pickling all relevant DType types/classes
  • #​18351: BUG: Fix missing signed_char dependency. Closes #​18335.
  • #​18352: DOC: Change license date 2020 -> 2021
  • #​18353: CI: CircleCI seems to occasionally time out, increase the limit
  • #​18354: BUG: Fix f2py bugs when wrapping F90 subroutines.
  • #​18356: MAINT: crackfortran regex simplify
  • #​18357: BUG: threads.h existence test requires GLIBC > 2.12.
  • #​18359: REL: Prepare for the NumPy 1.20.1 release.

Checksums

MD5
c4748f4f8f703c5e96027407eca02b08  numpy-1.20.1-cp37-cp37m-macosx_10_9_x86_64.whl
f0bf3a78d6b3a169e5a7fb2637f7fd87  numpy-1.20.1-cp37-cp37m-manylinux1_i686.whl
493c17647c05ca5043bcbab1ac266a74  numpy-1.20.1-cp37-cp37m-manylinux1_x86_64.whl
55ec954fc598c72b2bbf57bfa8b2a701  numpy-1.20.1-cp37-cp37m-manylinux2010_i686.whl
8cee88f9683d208686081522609a8726  numpy-1.20.1-cp37-cp37m-manylinux2010_x86_64.whl
26399d3ededc53b354de78f977a6197e  numpy-1.20.1-cp37-cp37m-manylinux2014_aarch64.whl
81051f1e7a79eea8a5aaf5718114ce3a  numpy-1.20.1-cp37-cp37m-win32.whl
899488c55824f02a7a6f0451fc86f63f  numpy-1.20.1-cp37-cp37m-win_amd64.whl
17f4dae5a0d143b46345a9cf1a8c8dec  numpy-1.20.1-cp38-cp38-macosx_10_9_x86_64.whl
f254e98e92b3054c567b6220b37b81d3  numpy-1.20.1-cp38-cp38-manylinux1_i686.whl
483f43a62c7e32ae991990786da90de1  numpy-1.20.1-cp38-cp38-manylinux1_x86_64.whl
bf578b783e36d3feb3344973306a9f96  numpy-1.20.1-cp38-cp38-manylinux2010_i686.whl
f5d6c77c898537017e64ee30b243fdca  numpy-1.20.1-cp38-cp38-manylinux2010_x86_64.whl
5cf541a0d5af3d5812d2970a427075fb  numpy-1.20.1-cp38-cp38-manylinux2014_aarch64.whl
178315c579c0a70285b8ee502eb498af  numpy-1.20.1-cp38-cp38-win32.whl
5164a32e7a00a2b285302b563eb58afe  numpy-1.20.1-cp38-cp38-win_amd64.whl
c123dd10788ea9ff788d735cbee444c5  numpy-1.20.1-cp39-cp39-macosx_10_9_x86_64.whl
72282fefe58650c6e7cc41f5b37b8662  numpy-1.20.1-cp39-cp39-manylinux2010_i686.whl
234d57c1a7b1f8b99c054a7a71a51cbe  numpy-1.20.1-cp39-cp39-manylinux2010_x86_64.whl
352243d4285970e45d825024ca566d47  numpy-1.20.1-cp39-cp39-manylinux2014_aarch64.whl
a78c863323e0f56210c2e1acaad1bc22  numpy-1.20.1-cp39-cp39-win32.whl
86f9d3f358e7d7896e713bce99f17fdd  numpy-1.20.1-cp39-cp39-win_amd64.whl
ed2c81132119fb3c7f73c6a2de306058  numpy-1.20.1-pp37-pypy37_pp73-manylinux2010_x86_64.whl
60a5e2517be19394a7df24f6d4add3f2  numpy-1.20.1.tar.gz
30ea1c7868e73eeff2c86ac465311220  numpy-1.20.1.zip
SHA256
ae61f02b84a0211abb56462a3b6cd1e7ec39d466d3160eb4e1da8bf6717cdbeb  numpy-1.20.1-cp37-cp37m-macosx_10_9_x86_64.whl
65410c7f4398a0047eea5cca9b74009ea61178efd78d1be9847fac1d6716ec1e  numpy-1.20.1-cp37-cp37m-manylinux1_i686.whl
2d7e27442599104ee08f4faed56bb87c55f8b10a5494ac2ead5c98a4b289e61f  numpy-1.20.1-cp37-cp37m-manylinux1_x86_64.whl
4ed8e96dc146e12c1c5cdd6fb9fd0757f2ba66048bf94c5126b7efebd12d0090  numpy-1.20.1-cp37-cp37m-manylinux2010_i686.whl
ecb5b74c702358cdc21268ff4c37f7466357871f53a30e6f84c686952bef16a9  numpy-1.20.1-cp37-cp37m-manylinux2010_x86_64.whl
b9410c0b6fed4a22554f072a86c361e417f0258838957b78bd063bde2c7f841f  numpy-1.20.1-cp37-cp37m-manylinux2014_aarch64.whl
3d3087e24e354c18fb35c454026af3ed8997cfd4997765266897c68d724e4845  numpy-1.20.1-cp37-cp37m-win32.whl
89f937b13b8dd17b0099c7c2e22066883c86ca1575a975f754babc8fbf8d69a9  numpy-1.20.1-cp37-cp37m-win_amd64.whl
a1d7995d1023335e67fb070b2fae6f5968f5be3802b15ad6d79d81ecaa014fe0  numpy-1.20.1-cp38-cp38-macosx_10_9_x86_64.whl
60759ab15c94dd0e1ed88241fd4fa3312db4e91d2c8f5a2d4cf3863fad83d65b  numpy-1.20.1-cp38-cp38-manylinux1_i686.whl
125a0e10ddd99a874fd357bfa1b636cd58deb78ba4a30b5ddb09f645c3512e04  numpy-1.20.1-cp38-cp38-manylinux1_x86_64.whl
c26287dfc888cf1e65181f39ea75e11f42ffc4f4529e5bd19add57ad458996e2  numpy-1.20.1-cp38-cp38-manylinux2010_i686.whl
7199109fa46277be503393be9250b983f325880766f847885607d9b13848f257  numpy-1.20.1-cp38-cp38-manylinux2010_x86_64.whl
72251e43ac426ff98ea802a931922c79b8d7596480300eb9f1b1e45e0543571e  numpy-1.20.1-cp38-cp38-manylinux2014_aarch64.whl
c91ec9569facd4757ade0888371eced2ecf49e7982ce5634cc2cf4e7331a4b14  numpy-1.20.1-cp38-cp38-win32.whl
13adf545732bb23a796914fe5f891a12bd74cf3d2986eed7b7eba2941eea1590  numpy-1.20.1-cp38-cp38-win_amd64.whl
104f5e90b143dbf298361a99ac1af4cf59131218a045ebf4ee5990b83cff5fab  numpy-1.20.1-cp39-cp39-macosx_10_9_x86_64.whl
89e5336f2bec0c726ac7e7cdae181b325a9c0ee24e604704ed830d241c5e47ff  numpy-1.20.1-cp39-cp39-manylinux2010_i686.whl
032be656d89bbf786d743fee11d01ef318b0781281241997558fa7950028dd29  numpy-1.20.1-cp39-cp39-manylinux2010_x86_64.whl
66b467adfcf628f66ea4ac6430ded0614f5cc06ba530d09571ea404789064adc  numpy-1.20.1-cp39-cp39-manylinux2014_aarch64.whl
12e4ba5c6420917571f1a5becc9338abbde71dd811ce40b37ba62dec7b39af6d  numpy-1.20.1-cp39-cp39-win32.whl
9c94cab5054bad82a70b2e77741271790304651d584e2cdfe2041488e753863b  numpy-1.20.1-cp39-cp39-win_amd64.whl
9eb551d122fadca7774b97db8a112b77231dcccda8e91a5bc99e79890797175e  numpy-1.20.1-pp37-pypy37_pp73-manylinux2010_x86_64.whl
9bf51d69ebb4ca9239e55bedc2185fe2c0ec222da0adee7ece4125414676846d  numpy-1.20.1.tar.gz
3bc63486a870294683980d76ec1e3efc786295ae00128f9ea38e2c6e74d5a60a  numpy-1.20.1.zip

v1.20.0

Compare Source

NumPy 1.20.0 Release Notes

This NumPy release is the largest so made to date, some 684 PRs
contributed by 184 people have been merged. See the list of highlights
below for more details. The Python versions supported for this release
are 3.7-3.9, support for Python 3.6 has been dropped. Highlights are

  • Annotations for NumPy functions. This work is ongoing and
    improvements can be expected pending feedback from users.
  • Wider use of SIMD to increase execution speed of ufuncs. Much work
    has been done in introducing universal functions that will ease use
    of modern features across different hardware platforms. This work is
    ongoing.
  • Preliminary work in changing the dtype and casting implementations
    in order to provide an easier path to extending dtypes. This work is
    ongoing but enough has been done to allow experimentation and
    feedback.
  • Extensive documentation improvements comprising some 185 PR merges.
    This work is ongoing and part of the larger project to improve
    NumPy\'s online presence and usefulness to new users.
  • Further cleanups related to removing Python 2.7. This improves code
    readability and removes technical debt.
  • Preliminary support for the upcoming Cython 3.0.

New functions

The random.Generator class has a new permuted function.

The new function differs from shuffle and permutation in that the
subarrays indexed by an axis are permuted rather than the axis being
treated as a separate 1-D array for every combination of the other
indexes. For example, it is now possible to permute the rows or columns
of a 2-D array.

(gh-15121)

sliding_window_view provides a sliding window view for numpy arrays

numpy.lib.stride\_tricks.sliding\_window\_view constructs
views on numpy arrays that offer a sliding or moving window access to
the array. This allows for the simple implementation of certain
algorithms, such as running means.

(gh-17394)

[numpy.broadcast_shapes]{.title-ref} is a new user-facing function

numpy.broadcast\_shapes gets the resulting shape from
broadcasting the given shape tuples against each other.

>>> np.broadcast_shapes((1, 2), (3, 1))
(3, 2)

>>> np.broadcast_shapes(2, (3, 1))
(3, 2)

>>> np.broadcast_shapes((6, 7), (5, 6, 1), (7,), (5, 1, 7))
(5, 6, 7)

(gh-17535)

Deprecations

Using the aliases of builtin types like np.int is deprecated

For a long time, np.int has been an alias of the builtin int. This
is repeatedly a cause of confusion for newcomers, and existed mainly for
historic reasons.

These aliases have been deprecated. The table below shows the full list
of deprecated aliases, along with their exact meaning. Replacing uses of
items in the first column with the contents of the second column will
work identically and silence the deprecation warning.

The third column lists alternative NumPy names which may occasionally be
preferential. See also basics.types{.interpreted-text role="ref"} for
additional details.

Deprecated name Identical to NumPy scalar type names
numpy.bool bool numpy.bool\_
numpy.int int numpy.int\_ (default), numpy.int64, or numpy.int32
numpy.float float numpy.float64, numpy.float\_, numpy.double (equivalent)
numpy.complex complex numpy.complex128, numpy.complex\_, numpy.cdouble (equivalent)
numpy.object object numpy.object\_
numpy.str str numpy.str\_
numpy.long int numpy.int\_(C long), numpy.longlong (largest integer type)
numpy.unicode str numpy.unicode\_

To give a clear guideline for the vast majority of cases, for the types
bool, object, str (and unicode) using the plain version is
shorter and clear, and generally a good replacement. For float and
complex you can use float64 and complex128 if you wish to be more
explicit about the precision.

For np.int a direct replacement with np.int_ or int is also good
and will not change behavior, but the precision will continue to depend
on the computer and operating system. If you want to be more explicit
and review the current use, you have the following alternatives:

  • np.int64 or np.int32 to specify the precision exactly. This
    ensures that results cannot depend on the computer or operating
    system.
  • np.int_ or int (the default), but be aware that it depends on
    the computer and operating system.
  • The C types: np.cint (int), np.int_ (long), np.longlong.
  • np.intp which is 32bit on 32bit machines 64bit on 64bit machines.
    This can be the best type to use for indexing.

When used with np.dtype(...) or dtype=... changing it to the NumPy
name as mentioned above will have no effect on the output. If used as a
scalar with:

np.float(123)

changing it can subtly change the result. In this case, the Python
version float(123) or int(12.) is normally preferable, although the
NumPy version may be useful for consistency with NumPy arrays (for
example, NumPy behaves differently for things like division by zero).

(gh-14882)

Passing shape=None to functions with a non-optional shape argument is deprecated

Previously, this was an alias for passing shape=(). This deprecation
is emitted by PyArray\_IntpConverter in the C API. If your
API is intended to support passing None, then you should check for
None prior to invoking the converter, so as to be able to distinguish
None and ().

(gh-15886)

Indexing errors will be reported even when index result is empty

In the future, NumPy will raise an IndexError when an integer array
index contains out of bound values even if a non-indexed dimension is of
length 0. This will now emit a DeprecationWarning. This can happen when
the array is previously empty, or an empty slice is involved:

arr1 = np.zeros((5, 0))
arr1[[20]]
arr2 = np.zeros((5, 5))
arr2[[20], :0]

Previously the non-empty index [20] was not checked for correctness.
It will now be checked causing a deprecation warning which will be
turned into an error. This also applies to assignments.

(gh-15900)

Inexact matches for mode and searchside are deprecated

Inexact and case insensitive matches for mode and searchside were
valid inputs earlier and will give a DeprecationWarning now. For
example, below are some example usages which are now deprecated and will
give a DeprecationWarning:

import numpy as np
arr = np.array([[3, 6, 6], [4, 5, 1]])

mode: inexact match

np.ravel_multi_index(arr, (7, 6), mode="clap")  # should be "clip"

searchside: inexact match

np.searchsorted(arr[0], 4, side='random')  # should be "right"

(gh-16056)

Deprecation of [numpy.dual]{.title-ref}

The module numpy.dual is deprecated. Instead of importing
functions from numpy.dual, the functions should be
imported directly from NumPy or SciPy.

(gh-16156)

outer and ufunc.outer deprecated for matrix

np.matrix use with \~numpy.outer or generic ufunc outer
calls such as numpy.add.outer. Previously, matrix was converted to an
array here. This will not be done in the future requiring a manual
conversion to arrays.

(gh-16232)

Further Numeric Style types Deprecated

The remaining numeric-style type codes Bytes0, Str0, Uint32,
Uint64, and Datetime64 have been deprecated. The lower-case variants
should be used instead. For bytes and string "S" and "U" are further
alternatives.

(gh-16554)

The ndincr method of ndindex is deprecated

The documentation has warned against using this function since NumPy
1.8. Use next(it) instead of it.ndincr().

(gh-17233)

ArrayLike objects which do not define __len__ and __getitem__

Objects which define one of the protocols __array__,
__array_interface__, or __array_struct__ but are not sequences
(usually defined by having a __len__ and __getitem__) will behave
differently during array-coercion in the future.

When nested inside sequences, such as np.array([array_like]), these
were handled as a single Python object rather than an array. In the
future they will behave identically to:

np.array([np.array(array_like)])

This change should only have an effect if np.array(array_like) is not
0-D. The solution to this warning may depend on the object:

  • Some array-likes may expect the new behaviour, and users can ignore
    the warning. The object can choose to expose the sequence protocol
    to opt-in to the new behaviour.
  • For example, shapely will allow conversion to an array-like using
    line.coords rather than np.asarray(line). Users may work around
    the warning, or use the new convention when it becomes available.

Unfortunately, using the new behaviour can only be achieved by calling
np.array(array_like).

If you wish to ensure that the old behaviour remains unchanged, please
create an object array and then fill it explicitly, for example:

arr = np.empty(3, dtype=object)
arr[:] = [array_like1, array_like2, array_like3]

This will ensure NumPy knows to not enter the array-like and use it as a
object instead.

(gh-17973)

Future Changes

Arrays cannot be using subarray dtypes

Array creation and casting using np.array(arr, dtype) and
arr.astype(dtype) will use different logic when dtype is a subarray
dtype such as np.dtype("(2)i,").

For such a dtype the following behaviour is true:

res = np.array(arr, dtype)

res.dtype is not dtype
res.dtype is dtype.base
res.shape == arr.shape + dtype.shape

But res is filled using the logic:

res = np.empty(arr.shape + dtype.shape, dtype=dtype.base)
res[...] = arr

which uses incorrect broadcasting (and often leads to an error). In the
future, this will instead cast each element individually, leading to the
same result as:

res = np.array(arr, dtype=np.dtype(["f", dtype]))["f"]

Which can normally be used to opt-in to the new behaviour.

This change does not affect np.array(list, dtype="(2)i,") unless the
list itself includes at least one array. In particular, the behaviour
is unchanged for a list of tuples.

(gh-17596)

Expired deprecations

  • The deprecation of numeric style type-codes np.dtype("Complex64")
    (with upper case spelling), is expired. "Complex64" corresponded
    to "complex128" and "Complex32" corresponded to "complex64".

  • The deprecation of np.sctypeNA and np.typeNA is expired. Both
    have been removed from the public API. Use np.typeDict instead.

    (gh-16554)

  • The 14-year deprecation of np.ctypeslib.ctypes_load_library is
    expired. Use ~numpy.ctypeslib.load_library{.interpreted-text
    role="func"} instead, which is identical.

    (gh-17116)

Financial functions removed

In accordance with NEP 32, the financial functions are removed from
NumPy 1.20. The functions that have been removed are fv, ipmt,
irr, mirr, nper, npv, pmt, ppmt, pv, and rate. These
functions are available in the
numpy_financial library.

(gh-17067)

Compatibility notes

isinstance(dtype, np.dtype) and not type(dtype) is not np.dtype

NumPy dtypes are not direct instances of np.dtype anymore. Code that
may have used type(dtype) is np.dtype will always return False and
must be updated to use the correct version
isinstance(dtype, np.dtype).

This change also affects the C-side macro PyArray_DescrCheck if
compiled against a NumPy older than 1.16.6. If code uses this macro and
wishes to compile against an older version of NumPy, it must replace the
macro (see also C API changes section).

Same kind casting in concatenate with axis=None

When [~numpy.concatenate]{.title-ref} is called with axis=None, the
flattened arrays were cast with unsafe. Any other axis choice uses
\"same kind\". That different default has been deprecated and \"same
kind\" casting will be used instead. The new casting keyword argument
can be used to retain the old behaviour.

(gh-16134)

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 strings 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"

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)])

This can subtly change output for some badly defined array-likes. One
example for this are array-like objects which are not also sequences of
matching shape. In NumPy 1.20, a warning will be given when an
array-like is not also a sequence (but behaviour remains identical, see
deprecations). If an array like is also a sequence (defines
__getitem__ and __len__) NumPy will now only use the result given by
__array__, __array_interface__, or __array_struct__. This will
result in differences when the (nested) sequence describes a different
shape.

(gh-16200)

Writing to the result of numpy.broadcast\_arrays will export readonly buffers

In NumPy 1.17 numpy.broadcast\_arrays started warning when
the resulting array was written to. This warning was skipped when the
array was used through the buffer interface (e.g. memoryview(arr)).
The same thing will now occur for the two protocols
__array_interface__, and __array_struct__ returning read-only
buffers instead of giving a warning.

(gh-16350)

Numeric-style type names have been removed from type dictionaries

To stay in sync with the deprecation for np.dtype("Complex64") and
other numeric-style (capital case) types. These were removed from
np.sctypeDict and np.typeDict. You should use the lower case
versions instead. Note that "Complex64" corresponds to "complex128"
and "Complex32" corresponds to "complex64". The numpy style (new)
versions, denote the full size and not the size of the real/imaginary
part.

(gh-16554)

The operator.concat function now raises TypeError for array arguments

The previous behavior was to fall back to addition and add the two
arrays, which was thought to be unexpected behavior for a concatenation
function.

(gh-16570)

nickname attribute removed from ABCPolyBase

An abstract property nickname has been removed from ABCPolyBase as
it was no longer used in the derived convenience classes. This may
affect users who have derived classes from ABCPolyBase and overridden
the methods for representation and display, e.g. __str__, __repr__,
_repr_latex, etc.

(gh-16589)

float->timedelta and uint64->timedelta promotion will raise a TypeError

Float and timedelta promotion consistently raises a TypeError.
np.promote_types("float32", "m8") aligns with
np.promote_types("m8", "float32") now and both raise a TypeError.
Previously, np.promote_types("float32", "m8") returned "m8" which
was considered a bug.

Uint64 and timedelta promotion consistently raises a TypeError.
np.promote_types("uint64", "m8") aligns with
np.promote_types("m8", "uint64") now and both raise a TypeError.
Previously, np.promote_types("uint64", "m8") returned "m8" which was
considered a bug.

(gh-16592)

numpy.genfromtxt now correctly unpacks structured arrays

Previously, numpy.genfromtxt failed to unpack if it was
called with unpack=True and a structured datatype was passed to the
dtype argument (or dtype=None was passed and a structured datatype
was inferred). For example:

>>> data = StringIO("21 58.0\n35 72.0")
>>> np.genfromtxt(data, dtype=None, unpack=True)
array([(21, 58.), (35, 72.)], dtype=[('f0', '<i8'), ('f1', '<f8')])

Structured arrays will now correctly unpack into a list of arrays, one
for each column:

>>> np.genfromtxt(data, dtype=None, unpack=True)
[array([21, 35]), array([58., 72.])]

(gh-16650)

mgrid, r_, etc. consistently return correct outputs for non-default precision input

Previously,
np.mgrid[np.float32(0.1):np.float32(0.35):np.float32(0.1),] and
np.r_[0:10:np.complex64(3j)] failed to return meaningful output. This
bug potentially affects [~numpy.mgrid]{.title-ref},
numpy.ogrid, numpy.r\_, and
numpy.c\_ when an input with dtype other than the
default float64 and complex128 and equivalent Python types were
used. The methods have been fixed to handle varying precision correctly.

(gh-16815)

Boolean array indices with mismatching shapes now properly give IndexError

Previously, if a boolean array index matched the size of the indexed
array but not the shape, it was incorrectly allowed in some cases. In
other cases, it gave an error, but the error was incorrectly a
ValueError with a message about broadcasting instead of the correct
IndexError.

For example, the following used to incorrectly give
ValueError: operands could not be broadcast together with shapes (2,2) (1,4):

np.empty((2, 2))[np.array([[True, False, False, False]])]

And the following used to incorrectly return array([], dtype=float64):

np.empty((2, 2))[np.array([[False, False, False, False]])]

Both now correctly give
IndexError: boolean index did not match indexed array along dimension 0; dimension is 2 but corresponding boolean dimension is 1.

(gh-17010)

Casting errors interrupt Iteration

When iterating while casting values, an error may stop the iteration
earlier than before. In any case, a failed casting operation always
returned undefined, partial results. Those may now be even more
undefined and partial. For users of the NpyIter C-API such cast errors
will now cause the [iternext()]{.title-ref} function to return 0 and
thus abort iteration. Currently, there is no API to detect such an error
directly. It is necessary to check PyErr_Occurred(), which may be
problematic in combination with NpyIter_Reset. These issues always
existed, but new API could be added if required by users.

(gh-17029)

f2py generated code may return unicode instead of byte strings

Some byte strings previously returned by f2py generated code may now be
unicode strings. This results from the ongoing Python2 -> Python3
cleanup.

(gh-17068)

The first element of the __array_interface__["data"] tuple must be an integer

This has been the documented interface for many years, but there was
still code that would accept a byte string representation of the pointer
address. That code has been removed, passing the address as a byte
string will now raise an error.

(gh-17241)

poly1d respects the dtype of all-zero argument

Previously, constructing an instance of poly1d with all-zero
coefficients would cast the coefficients to np.float64. This affected
the output dtype of methods which construct poly1d instances
internally, such as np.polymul.

(gh-17577)

The numpy.i file for swig is Python 3 only.

Uses of Python 2.7 C-API functions have been updated to Python 3 only.
Users who need the old version should take it from an older version of
NumPy.

(gh-17580)

Void dtype discovery in np.array

In calls using np.array(..., dtype="V"), arr.astype("V"), and
similar a TypeError will now be correctly raised unless all elements
have the identical void length. An example for this is:

np.array([b"1", b"12"], dtype="V")

Which previously returned an array with dtype "V2" which cannot
represent b"1" faithfully.

(gh-17706)

C API changes

The PyArray_DescrCheck macro is modified

The PyArray_DescrCheck macro has been updated since NumPy 1.16.6 to
be:

#define PyArray_DescrCheck(op) PyObject_TypeCheck(op, &PyArrayDescr_Type)

Starting with NumPy 1.20 code that is compiled against an earlier
version will be API incompatible with NumPy 1.20. The fix is to either
compile against 1.16.6 (if the NumPy 1.16 release is the oldest release
you wish to support), or manually inline the macro by replacing it with
the new definition:

PyObject_TypeCheck(op, &PyArrayDescr_Type)

which is compatible with all NumPy versions.

Size of np.ndarray and np.void_ changed

The size of the PyArrayObject and PyVoidScalarObject structures have
changed. The following header definition has been removed:

#define NPY_SIZEOF_PYARRAYOBJECT (sizeof(PyArrayObject_fields))

since the size must not be considered a compile time constant: it will
change for different runtime versions of NumPy.

The most likely relevant use are potential subclasses written in C which
will have to be recompiled and should be updated. Please see the
documentation for :cPyArrayObject{.interpreted-text role="type"} for
more details and contact the NumPy developers if you are affected by
this change.

NumPy will attempt to give a graceful error but a program expecting a
fixed structure size may have undefined behaviour and likely crash.

(gh-16938)

New Features

where keyword argument for numpy.all and numpy.any functions

The keyword argument where is added and allows to only consider
specified elements or subaxes from an array in the Boolean evaluation of
all and any. This new keyword is available to the functions all
and any both via numpy directly or in the methods of
numpy.ndarray.

Any broadcastable Boolean array or a scalar can be set as where. It
defaults to True to evaluate the functions for all elements in an
array if where is not set by the user. Examples are given in the
documentation of the functions.

where keyword argument for numpy functions mean, std, var

The keyword argument where is added and allows to limit the scope in
the calculation of mean, std and var to only a subset of elements.
It is available both via numpy directly or in the methods of
numpy.ndarray.

Any broadcastable Boolean array or a scalar can be set as where. It
defaults to True to evaluate the functions for all elements in an
array if where is not set by the user. Examples are given in the
documentation of the functions.

(gh-15852)

norm=backward, forward keyword options for numpy.fft functions

The keyword argument option norm=backward is added as an alias for
None and acts as the default option; using it has the direct
transforms unscaled and the inverse transforms scaled by 1/n.

Using the new keyword argument option norm=forward has the direct
transforms scaled by 1/n and the inverse transforms unscaled (i.e.
exactly opposite to the default option norm=backward).

(gh-16476)

NumPy is now typed

Type annotations have been added for large parts of NumPy. There is also
a new [numpy.typing]{.title-ref} module that contains useful types for
end-users. The currently available types are

  • ArrayLike: for objects that can be coerced to an array
  • DtypeLike: for objects that can be coerced to a dtype

(gh-16515)

numpy.typing is accessible at runtime

The types in numpy.typing can now be imported at runtime. Code like
the following will now work:

from numpy.typing import ArrayLike
x: ArrayLike = [1, 2, 3, 4]

(gh-16558)

New __f2py_numpy_version__ attribute for f2py generated modules.

Because f2py is released together with NumPy, __f2py_numpy_version__
provides a way to track the version f2py used to generate the module.

(gh-16594)

mypy tests can be run via runtests.py

Currently running mypy with the NumPy stubs configured requires either:

  • Installing NumPy
  • Adding the source directory to MYPYPATH and linking to the
    mypy.ini

Both options are somewhat inconvenient, so add a --mypy option to
runtests that handles setting things up for you. This will also be
useful in the future for any typing codegen since it will ensure the
project is built before type checking.

(gh-17123)

Negation of user defined BLAS/LAPACK detection order

[~numpy.distutils]{.title-ref} allows negation of libraries when
determining BLAS/LAPACK libraries. This may be used to remove an item
from the library resolution phase, i.e. to disallow NetLIB libraries one
could do:

NPY_BLAS_ORDER='^blas' NPY_LAPACK_ORDER='^lapack' python setup.py build

That will use any of the accelerated libraries instead.

(gh-17219)

Allow passing optimizations arguments to asv build

It is now possible to pass -j, --cpu-baseline, --cpu-dispatch and
--disable-optimization flags to ASV build when the --bench-compare
argument is used.

(gh-17284)

The NVIDIA HPC SDK nvfortran compiler is now supported

Support for the nvfortran compiler, a version of pgfortran, has been
added.

(gh-17344)

dtype option for cov and corrcoef

The dtype option is now available for [numpy.cov]{.title-ref} and
[numpy.corrcoef]{.title-ref}. It specifies which data-type the returned
result should have. By default the functions still return a
[numpy.float64]{.title-ref} result.

(gh-17456)

Improvements

Improved string representation for polynomials (__str__)

The string representation (__str__) of all six polynomial types in
[numpy.polynomial]{.title-ref} has been updated to give the polynomial
as a mathematical expression instead of an array of coefficients. Two
package-wide formats for the polynomial expressions are available - one
using Unicode characters for superscripts and subscripts, and another
using only ASCII characters.

(gh-15666)

Remove the Accelerate library as a candidate LAPACK library

Apple no longer supports Accelerate. Remove it.

(gh-15759)

Object arrays containing multi-line objects have a more readable repr

If elements of an object array have a repr containing new lines, then
the wrapped lines will be aligned by column. Notably, this improves the
repr of nested arrays:

>>> np.array([np.eye(2), np.eye(3)], dtype=object)
array([array([[1., 0.],
              [0., 1.]]),
       array([[1., 0., 0.],
              [0., 1., 0.],
              [0., 0., 1.]])], dtype=object)

(gh-15997)

Concatenate supports providing an output dtype

Support was added to [~numpy.concatenate]{.title-ref} to provide an
output dtype and casting using keyword arguments. The dtype
argument cannot be provided in conjunction with the out one.

(gh-16134)

Thread safe f2py callback functions

Callback functions in f2py are now thread safe.

(gh-16519)

[numpy.core.records.fromfile]{.title-ref} now supports file-like objects

[numpy.rec.fromfile]{.title-ref} can now use file-like objects, for
instance :pyio.BytesIO{.interpreted-text role="class"}

(gh-16675)

RPATH support on AIX added to distutils

This allows SciPy to be built on AIX.

(gh-16710)

Use f90 compiler specified by the command line args

The compiler command selection for Fortran Portland Group Compiler is
changed in [numpy.distutils.fcompiler]{.title-ref}. This only affects
the linking command. This forces the use of the executable provided by
the command line option (if provided) instead of the pgfortran
executable. If no executable is provided to the command line option it
defaults to the pgf90 executable, wich is an alias for pgfortran
according to the PGI documentation.

(gh-16730)

Add NumPy declarations for Cython 3.0 and later

The pxd declarations for Cython 3.0 were improved to avoid using
deprecated NumPy C-API features. Extension modules built with Cython
3.0+ that use NumPy can now set the C macro
NPY_NO_DEPRECATED_API=NPY_1_7_API_VERSION to avoid C compiler warnings
about deprecated API usage.

(gh-16986)

Make the window functions exactly symmetric

Make sure the window functions provided by NumPy are symmetric. There
were previously small deviations from symmetry due to numerical
precision that are now avoided by better arrangement of the computation.

(gh-17195)

Performance improvements and changes

Enable multi-platform SIMD compiler optimizations

A series of improvements for NumPy infrastructure to pave the way to
NEP-38, that can be summarized as follow:

  • New Build Arguments

    • --cpu-baseline to specify the minimal set of required
      optimizations, default value is min which provides the minimum
      CPU features that can safely run on a wide range of users
      platforms.
    • --cpu-dispatch to specify the dispatched set of additional
      optimizations, default value is max -xop -fma4 which enables
      all CPU features, except for AMD legacy features.
    • --disable-optimization to explicitly disable the whole new
      improvements, It also adds a new C compiler #definition
      called NPY_DISABLE_OPTIMIZATION which it can be used as guard
      for any SIMD code.
  • Advanced CPU dispatcher

    A flexible cross-architecture CPU dispatcher built on the top of
    Python/Numpy distutils, support all common compilers with a wide
    range of CPU features.

    The new dispatcher requires a special file extension *.dispatch.c
    to mark the dispatch-able C sources. These sources have the
    ability to be compiled multiple times so that each compilation
    process represents certain CPU features and provides different
    #definitions and flags that affect the code paths.

  • New auto-generated C header
    ``core/src/common/_cpu_dispatch.h``

    This header is generated by the distutils module ccompiler_opt,
    and contains all the #definitions and headers of instruction sets,
    that had been configured through command arguments
    \'--cpu-baseline\' and \'--cpu-dispatch\'.

  • New C header ``core/src/common/npy_cpu_dispatch.h``

    This header contains all utilities that required for the whole CPU
    dispatching process, it also can be considered as a bridge linking
    the new infrastructure work with NumPy CPU runtime detection.

  • Add new attributes to NumPy umath module(Python level)

    • __cpu_baseline__ a list contains the minimal set of required
      optimizations that supported by the compiler and platform
      according to the specified values to command argument
      \'--cpu-baseline\'.
    • __cpu_dispatch__ a list contains the dispatched set of
      additional optimizations that supported by the compiler and
      platform according to the specified values to command argument
      \'--cpu-dispatch\'.
  • Print the supported CPU features during the run of PytestTester

(gh-13516)

Changes

Changed behavior of divmod(1., 0.) and related functions

The changes also assure that different compiler versions have the same
behavior for nan or inf usages in these operations. This was previously
compiler dependent, we now force the invalid and divide by zero flags,
making the results the same across compilers. For example, gcc-5, gcc-8,
or gcc-9 now result in the same behavior. The changes are tabulated
below:

Operator Old Warning New Warning Old Result New Result Works on MacOS
np.divmod(1.0, 0.0) Invalid Invalid and Dividebyzero nan, nan inf, nan Yes
np.fmod(1.0, 0.0) Invalid Invalid nan nan No? Yes
np.floor_divide(1.0, 0.0) Invalid Dividebyzero nan inf Yes
np.remainder(1.0, 0.0) Invalid Invalid nan nan Yes

: Summary of New Behavior

(gh-16161)

np.linspace on integers now uses floor

When using a int dtype in [numpy.linspace]{.title-ref}, previously
float values would be rounded towards zero. Now
[numpy.floor]{.title-ref} is used instead, which rounds toward -inf.
This changes the results for negative values. For example, the following
would previously give:

>>> np.linspace(-3, 1, 8, dtype=int)
array([-3, -2, -1, -1,  0,  0,  0,  1])

and now results in:

>>> np.linspace(-3, 1, 8, dtype=int)
array([-3, -3, -2, -2, -1, -1,  0,  1])

The former result can still be obtained with:

>>> np.linspace(-3, 1, 8).astype(int)
array([-3, -2, -1, -1,  0,  0,  0,  1])

(gh-16841)

Checksums

MD5
6f43f51475706d8346cee9604ed54e8a  numpy-1.20.0-cp37-cp37m-macosx_10_9_x86_64.whl
c77f563595ab4bab6185c795c573a26a  numpy-1.20.0-cp37-cp37m-manylinux1_i686.whl
e8f71fdb7e4e837ae79894b621e3ca08  numpy-1.20.0-cp37-cp37m-manylinux1_x86_64.whl
89c477a3eaf2e3379aa21bf80e2a2812  numpy-1.20.0-cp37-cp37m-manylinux2010_i686.whl
82211490e9375bdad57592139b49184d  numpy-1.20.0-cp37-cp37m-manylinux2010_x86_64.whl
b2d47be4aa123623b39f18723e0d70b7  numpy-1.20.0-cp37-cp37m-manylinux2014_aarch64.whl
e884b218dc2b20895f57fae00534e8ea  numpy-1.20.0-cp37-cp37m-win32.whl
ec8265d429e808d8f92ed46711d66bc7  numpy-1.20.0-cp37-cp37m-win_amd64.whl
791cc5086a755929a1140018067c4587  numpy-1.20.0-cp38-cp38-macosx_10_9_x86_64.whl
2ee146bad9aa521d0bdfd7e30e982a80  numpy-1.20.0-cp38-cp38-manylinux1_i686.whl
83d74204a26e9dd3cb93653818745d09  numpy-1.20.0-cp38-cp38-manylinux1_x86_64.whl
0b0a5e36d4b75a00603cec4db09c44d7  numpy-1.20.0-cp38-cp38-manylinux2010_i686.whl
c192aeac728a3abfbd16daef87b2a307  numpy-1.20.0-cp38-cp38-manylinux2010_x86_64.whl
2282da14106cb52bbf9c8c0b847c3480  numpy-1.20.0-cp38-cp38-manylinux2014_aarch64.whl
0e0e4bf53dd8ea4e232083e788419f30  numpy-1.20.0-cp38-cp38-win32.whl
93ebb884970cf7292778cb19e9f27596  numpy-1.20.0-cp38-cp38-win_amd64.whl
749cca75b33849a78e7238aeb09baded  numpy-1.20.0-cp39-cp39-macosx_10_9_x86_64.whl
e36e7e259bb38ccd2320f88a137115e0  numpy-1.20.0-cp39-cp39-manylinux2010_i686.whl
4979a98a2cf0a1b14a82630b717aa12b  numpy-1.20.0-cp39-cp39-manylinux2010_x86_64.whl
52a78d15f15959003047ccb6b66a0ee7  numpy-1.20.0-cp39-cp39-manylinux2014_aarch64.whl
796b273028c7724a855214ae9a83e4f8  numpy-1.20.0-cp39-cp39-win32.whl
663428d8bedc5785041800ce098368cd  numpy-1.20.0-cp39-cp39-win_amd64.whl
66ea4e7911de7fdce688c1b69f9c7c54  numpy-1.20.0-pp37-pypy37_pp73-manylinux2010_x86_64.whl
fc7c970084438911a50efaa8cddccebc  numpy-1.20.0.tar.gz
024eb99dba56c3021458caf86f2fea0a  numpy-1.20.0.zip
SHA256
89bd70c9ad540febe6c28451ba225eb4e49d27f64728357f512c808002325dfa  numpy-1.20.0-cp37-cp37m-macosx_10_9_x86_64.whl
1264c66129f5ef63187649dd43f1ca59532e8c098723643336a85131c0dcce3f  numpy-1.20.0-cp37-cp37m-manylinux1_i686.whl
e9c5fd330d2fedf06051bafb996252de9b032fcb2ec03eefc9a543e56efa66d4  numpy-1.20.0-cp37-cp37m-manylinux1_x86_64.whl
db5e69d08756a2fa75a42b4e433880b6187768fe1bc73d21819def893e5128c6  numpy-1.20.0-cp37-cp37m-manylinux2010_i686.whl
1abc02e30e3efd81a4571e00f8e62bf42e343c76698e0a3e11d9c2b3ee0d77a7  numpy-1.20.0-cp37-cp37m-manylinux2010_x86_64.whl
5ae765dd29c71a555f8102281f6fb15a3f4dbd35f6e7daf36af9df6d9dd716a5  numpy-1.20.0-cp37-cp37m-manylinux2014_aarch64.whl
b51b9ef0624f4b01b846c981034c10d2e30db33f9f8be71e992f3900741f6f77  numpy-1.20.0-cp37-cp37m-win32.whl
afeee581b50df20ef07b736e62ca612858f1fcdba96651d26ab44e3d567a4e6e  numpy-1.20.0-cp37-cp37m-win_amd64.whl
2bf0e68c92ef077fe766e53f8937d8ac341bdbca68ec128ae049b7d5c34e3206  numpy-1.20.0-cp38-cp38-macosx_10_9_x86_64.whl
2445a96fbae23a4109c61be0f0af0f3bc273905dc5687a710850c1dfde0fc994  numpy-1.20.0-cp38-cp38-manylinux1_i686.whl
33edfc0eb229f86f539493917b34035054313a11afbed48404aaf9f86bf4b0f6  numpy-1.20.0-cp38-cp38-manylinux1_x86_64.whl
894aaee60043a98b03f0ad992c810f62e3a15f98a701e1c0f58a4f4a0df13429  numpy-1.20.0-cp38-cp38-manylinux2010_i686.whl
b66a6c15d793eda7cdad986e737775aa31b9306d588c14dd0277d2dda5546150  numpy-1.20.0-cp38-cp38-manylinux2010_x86_64.whl
eee454d3aa3955d0c0069a0f265fea47f1e1384c35a110a95efed358eb6e1562  numpy-1.20.0-cp38-cp38-manylinux2014_aarch64.whl
abdfa075e293d73638ece434708aa60b510dc6e70d805f57f481a0f550b25a9e  numpy-1.20.0-cp38-cp38-win32.whl
f1e9424e9aa3834ea27cc12f9c6ea8ace5da18ee60a720bb3a85b2f733f41782  numpy-1.20.0-cp38-cp38-win_amd64.whl
cb257bb0c0a3176c32782a63cfab2eace7eabfa2a3b2dfd85a13700617ccaf28  numpy-1.20.0-cp39-cp39-macosx_10_9_x86_64.whl
cf5d9dcbdbe523fa665c5309cce5f144648d94a7fddbf5a40f8e0d5c9f5b596d  numpy-1.20.0-cp39-cp39-manylinux2010_i686.whl
93c2abea7bb69f47029b84ceac30ab46dfcfdb99b671ad850a333ff794a765e4  numpy-1.20.0-cp39-cp39-manylinux2010_x86_64.whl
0d28a54afcf46f1f9ebd163e49ad6b49087f22986fefd01a23ca0c1cdda25ca6  numpy-1.20.0-cp39-cp39-manylinux2014_aarch64.whl
d1bc331e1706fd1809a1bc8a31205329e5b30cf5ba50461c624da267e99f6ae6  numpy-1.20.0-cp39-cp39-win32.whl
e3db646af9f6a145f0c57202f4b55d4a33f975e395e78fb7b394644c17c1a3a6  numpy-1.20.0-cp39-cp39-win_amd64.whl
4d592264d2a4f368afbb4288b5ceb646d4cbaf559c0249c096fbb0a149806b90  numpy-1.20.0-pp37-pypy37_pp73-manylinux2010_x86_64.whl
67b630745a71b541ff6517d6f3d62b00690dc8ba0684cad0d7b0ac55aec1de53  numpy-1.20.0.tar.gz
3d8233c03f116d068d5365fed4477f2947c7229582dad81e5953088989294cec  numpy-1.20.0.zip

Renovate configuration

📅 Schedule: At any time (no schedule defined).

🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.

♻️ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.

🔕 Ignore: Close this PR and you won't be reminded about this update again.


  • If you want to rebase/retry this PR, check this box

This PR has been generated by WhiteSource Renovate. View repository job log here.

@renovate renovate bot requested a review from bsoyka as a code owner February 22, 2021 18:51
@renovate renovate bot changed the title Update dependency numpy to v1.20.1 Update dependency numpy to v1.20.1 - autoclosed Feb 23, 2021
@renovate renovate bot closed this Feb 23, 2021
@renovate renovate bot deleted the renovate/numpy-1.x branch February 23, 2021 00:46
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

1 participant