codecov-io
commented
3 years ago Codecov Report
Merging #26 (ab775f4) into main (7b69111) will decrease coverage by
0.46%. The diff coverage isn/a.
@@ Coverage Diff @@
## main #26 +/- ##
==========================================
- Coverage 92.36% 91.89% -0.47%
==========================================
Files 23 23
Lines 1074 1074
==========================================
- Hits 992 987 -5
- Misses 82 87 +5 | Impacted Files | Coverage Δ | |
|---|---|---|
| ...centralized/cooperative_astar/cooperative_astar.py | 86.66% <0.00%> (-4.45%) |
:arrow_down: |
| pymapf/centralized/cooperative_astar/astar.py | 82.85% <0.00%> (-4.29%) |
:arrow_down: |
Continue to review full report at Codecov.
Legend - Click here to learn more
Δ = absolute <relative> (impact),ø = not affected,? = missing dataPowered by Codecov. Last update 7b69111...ab775f4. Read the comment docs.
This PR contains the following updates:
==1.19.5->==1.20.0Release Notes
numpy/numpy
### [`v1.20.0`](https://togithub.com/numpy/numpy/releases/v1.20.0) [Compare Source](https://togithub.com/numpy/numpy/compare/v1.19.5...v1.20.0) ### 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](https://togithub.com/numpy/numpy/pull/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](https://togithub.com/numpy/numpy/pull/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. ```{.python} >>> 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](https://togithub.com/numpy/numpy/pull/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](https://togithub.com/numpy/numpy/pull/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](https://togithub.com/numpy/numpy/pull/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](https://togithub.com/numpy/numpy/pull/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](https://togithub.com/numpy/numpy/pull/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](https://togithub.com/numpy/numpy/pull/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](https://togithub.com/numpy/numpy/pull/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](https://togithub.com/numpy/numpy/pull/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](https://togithub.com/numpy/numpy/pull/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](https://togithub.com/numpy/numpy/pull/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](https://togithub.com/numpy/numpy/pull/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](https://togithub.com/numpy/numpy/pull/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](https://togithub.com/numpy/numpy/pull/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](https://pypi.org/project/numpy-financial) library. ([gh-17067](https://togithub.com/numpy/numpy/pull/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](#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](https://togithub.com/numpy/numpy/pull/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](https://togithub.com/numpy/numpy/pull/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](https://togithub.com/numpy/numpy/pull/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](https://togithub.com/numpy/numpy/pull/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](https://togithub.com/numpy/numpy/pull/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](https://togithub.com/numpy/numpy/pull/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](https://togithub.com/numpy/numpy/pull/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', 'Renovate configuration
:date: Schedule: At any time (no schedule defined).
:vertical_traffic_light: Automerge: Disabled by config. Please merge this manually once you are satisfied.
:recycle: Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.
:no_bell: Ignore: Close this PR and you won't be reminded about this update again.
This PR has been generated by WhiteSource Renovate. View repository job log here.