NumPy v1.20.0.rc1 Release Notes

Release Date: 2020-12-03 // over 3 years ago
  • ๐Ÿš€ NumPy 1.20.0 Release Notes

    ๐Ÿš€ This NumPy release is the largest so made to date, some 654 PRs
    ๐Ÿ‘€ contributed by 182 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]{.title-ref} 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]{.title-ref} 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 is also simply not
    ๐Ÿ‘‰ useful.

    ๐Ÿ—„ 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.

    In many cases, it may have been intended to use the types from the third
    column. Be aware that use of these types may result in subtle but
    desirable behavior changes.

    ๐Ÿ—„ Deprecated name Identical to Possibly intended numpy type


    numpy.boolbool [numpy.bool_]{.title-ref}
    0๏ธโƒฃ numpy.intint [numpy.int_]{.title-ref} (default int dtype), [numpy.cint]{.title-ref} (C int)
    numpy.floatfloat [numpy.float_]{.title-ref}, [numpy.double]{.title-ref} (equivalent)
    numpy.complexcomplex [numpy.complex_]{.title-ref}, [numpy.cdouble]{.title-ref} (equivalent)
    numpy.objectobject [numpy.object_]{.title-ref}
    numpy.strstr [numpy.str_]{.title-ref}
    numpy.longint (long on Python 2) [numpy.int_]{.title-ref} (C long), [numpy.longlong]{.title-ref} (largest integer type)
    numpy.unicodestr (unicode on Python 2) [numpy.unicode_]{.title-ref}

    ๐Ÿ—„ Note that for technical reasons these deprecation warnings will only be
    emitted on Python 3.7 and above.

    (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]{.title-ref} 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]{.title-ref} is deprecated. Instead of importing
    functions from [numpy.dual]{.title-ref}, 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]{.title-ref} 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)

    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

    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 could potentially subtly change output for badly defined
    array-likes. We are not aware of any such case where the results were
    not clearly incorrect previously.

    (gh-16200)

    Writing to the result of [numpy.broadcast_arrays]{.title-ref} will export readonly buffers

    โš  In NumPy 1.17 [numpy.broadcast_arrays]{.title-ref} 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]{.title-ref} 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)

    0๏ธโƒฃ 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]{.title-ref}, [~numpy.r_]{.title-ref}, and
    [~numpy.c_]{.title-ref} when an input with dtype other than the
    0๏ธโƒฃ 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

    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
    0๏ธโƒฃ 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
    0๏ธโƒฃ 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
    0๏ธโƒฃ 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.
    0๏ธโƒฃ 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
    0๏ธโƒฃ 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
    0๏ธโƒฃ 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
      0๏ธโƒฃ 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
      0๏ธโƒฃ 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

    c182567139ec82a140d5fbf363ed1697 numpy-1.20.0rc1-cp37-cp37m-macosx_10_9_x86_64.whl
    06de963440e3dcf0dfd619a2b4936e59 numpy-1.20.0rc1-cp37-cp37m-manylinux1_i686.whl
    436a34182e234dce16bc597929a61313 numpy-1.20.0rc1-cp37-cp37m-manylinux1_x86_64.whl
    73aa4c274c2aee36f5f4d1c58b74a4a8 numpy-1.20.0rc1-cp37-cp37m-manylinux2010_i686.whl
    cc0bbd29cca3f80dbb09a3177df6b677 numpy-1.20.0rc1-cp37-cp37m-manylinux2010_x86_64.whl
    be993784ee6c9e9e95f949071f30a853 numpy-1.20.0rc1-cp37-cp37m-manylinux2014_aarch64.whl
    971e01facbe869f95dda518ecc0b4c09 numpy-1.20.0rc1-cp37-cp37m-win32.whl
    951e744fb554af874a0ba4bdbeedc882 numpy-1.20.0rc1-cp37-cp37m-win_amd64.whl
    197de0d040463b4d6026e83284f272ac numpy-1.20.0rc1-cp38-cp38-macosx_10_9_x86_64.whl
    27f146dbee25d7058def106f5c15eca0 numpy-1.20.0rc1-cp38-cp38-manylinux1_i686.whl
    b0f5ec0b31566270f8546a79d73e3424 numpy-1.20.0rc1-cp38-cp38-manylinux1_x86_64.whl
    2e9c06be7d826451b9227b11b3e6cd69 numpy-1.20.0rc1-cp38-cp38-manylinux2010_i686.whl
    f9fb7537b1e8197824f47650e883c63d numpy-1.20.0rc1-cp38-cp38-manylinux2010_x86_64.whl
    83ad71e9a7a46947e2fe203e3f822ad3 numpy-1.20.0rc1-cp38-cp38-manylinux2014_aarch64.whl
    318da96660e8c8ce5bac22e851969d15 numpy-1.20.0rc1-cp38-cp38-win32.whl
    051419fe996b984eced3a6e28320a45a numpy-1.20.0rc1-cp38-cp38-win_amd64.whl
    bca434dd07cd58b2436e592efc72c10b numpy-1.20.0rc1-cp39-cp39-macosx_10_9_x86_64.whl
    91beb7602bc10db4a912b9de8d082efe numpy-1.20.0rc1-cp39-cp39-manylinux2010_i686.whl
    d213368ea0f28697597041ab175242f1 numpy-1.20.0rc1-cp39-cp39-manylinux2010_x86_64.whl
    c1f3936e707014e1683eaeae30b71649 numpy-1.20.0rc1-cp39-cp39-manylinux2014_aarch64.whl
    d4881ad35eb820a5e3a27bb47adcbb2b numpy-1.20.0rc1-cp39-cp39-win32.whl
    ae4a01a84de51a0957452611dbad1199 numpy-1.20.0rc1-cp39-cp39-win_amd64.whl
    c3d85a1bada3081b917ee9498ec4fb08 numpy-1.20.0rc1-pp37-pypy37_pp73-manylinux2010_x86_64.whl
    94bb7d8f42e03c0c1cd37c230fcdfc14 numpy-1.20.0rc1.tar.gz
    1ed93be9e6bfb1de153af93d20c4e443 numpy-1.20.0rc1.zip
    

    SHA256

    01e9029472857f8dd9868e1f83f3ff9df0b477e9e7554bc4455eb5293b8ae335 numpy-1.20.0rc1-cp37-cp37m-macosx_10_9_x86_64.whl
    c6545bc46b3e4accaff4c542b4b4b95993ef0e4d74bb86fe19189b630740f76e numpy-1.20.0rc1-cp37-cp37m-manylinux1_i686.whl
    b028d1104eb8f7c5f0bc5bdc4c35768efc755b459f3a67b38a79eb9b86e354c2 numpy-1.20.0rc1-cp37-cp37m-manylinux1_x86_64.whl
    4789ad6cc531c9a24ce8cff59ac3c669e307599fba2bd40c2bc700d5b3013105 numpy-1.20.0rc1-cp37-cp37m-manylinux2010_i686.whl
    e9b0138142f72a3c143f262fd435b331e9807a2eb1c0e2ff6904f2cdc9b9b1a5 numpy-1.20.0rc1-cp37-cp37m-manylinux2010_x86_64.whl
    a2a4d00b119c71ba83fc1dd0f4dc71e2dd0fd61acd5cbd40541da4f9172427d3 numpy-1.20.0rc1-cp37-cp37m-manylinux2014_aarch64.whl
    dcee4823291188e213d681b05a2749ff36a87d4933a91b9654fcf0e2bf02ce4a numpy-1.20.0rc1-cp37-cp37m-win32.whl
    b1cf3925dda0920ee469c95260d2313f1f4a8d6381d42cfdd607e6fd991c4256 numpy-1.20.0rc1-cp37-cp37m-win_amd64.whl
    10baa94959bcbea0070e82e7ed3db9090fbaf267811a74701bdc0a0697dfe2ae numpy-1.20.0rc1-cp38-cp38-macosx_10_9_x86_64.whl
    7f7f08cc1a3415a61382a2c60bd71d5bd3efa33ee90ebc14ce4754dfa0a138c9 numpy-1.20.0rc1-cp38-cp38-manylinux1_i686.whl
    1a544c8d7928c85fcfb3af1649aad7d60376e89f9bc5be89f6da6d5eff1ed107 numpy-1.20.0rc1-cp38-cp38-manylinux1_x86_64.whl
    c9a21184a9b40793bc17a1456c3713a98c9466af2d1f849354cef0a756e2f7c6 numpy-1.20.0rc1-cp38-cp38-manylinux2010_i686.whl
    09fcbaef175786b99287039ada5dcf2c9131b65ceab1807fa9a61e5b062091a8 numpy-1.20.0rc1-cp38-cp38-manylinux2010_x86_64.whl
    ce8c2a2fbfdaf14fd7ed85e9a10bea9247f9f884bf504ed773aee8c0adcee220 numpy-1.20.0rc1-cp38-cp38-manylinux2014_aarch64.whl
    dd298a8efe8c62acb94797932d39ad3b74d1c4c1f496fa259b28a677e8f4793e numpy-1.20.0rc1-cp38-cp38-win32.whl
    55dcf4a830d1198a72b6afb72cb02879c3abb95024c250402851de66db94a30d numpy-1.20.0rc1-cp38-cp38-win_amd64.whl
    76cda96f70435bf75cac28dd081bb9e47e8eaf2badd1d9ad5ab19723d74e5921 numpy-1.20.0rc1-cp39-cp39-macosx_10_9_x86_64.whl
    ed955ab39527f7500b31dae6075b00f284a0c2eb23e7fd1a5a40a5066cab309f numpy-1.20.0rc1-cp39-cp39-manylinux2010_i686.whl
    b38a2caf64429bab2c06b87eea0d2b24f736894f805f3d7210ecafb5573cb0de numpy-1.20.0rc1-cp39-cp39-manylinux2010_x86_64.whl
    14aa454e438290d1ce464c80530157dc1ece86e34dd79a8077ca0e05ebab3665 numpy-1.20.0rc1-cp39-cp39-manylinux2014_aarch64.whl
    3c27251c07f8e3cd727cab8cc275c1294be006ed725496090a6081f6d8d1d811 numpy-1.20.0rc1-cp39-cp39-win32.whl
    4925c540f1bde557987c2d0b258b9c57cb6da020957ffa4ac355f13d6819b121 numpy-1.20.0rc1-cp39-cp39-win_amd64.whl
    e9a5652afbe2128cb1734546608a0a0d5dbd21160738a40521464d7cb4cc22b5 numpy-1.20.0rc1-pp37-pypy37_pp73-manylinux2010_x86_64.whl
    b4993844022e98fe363467ce42404ffd6f975239d294b6e4ea44a6e797891fac numpy-1.20.0rc1.tar.gz
    98f4e754f1c3db7ca53e53b1ef6474703b167af75f3784f99b1fe4dd936ea77f numpy-1.20.0rc1.zip