8000 ENH: pathlib support for fromfile(), .tofile() and .dump() by sorenrasmussenai · Pull Request #12915 · numpy/numpy · GitHub
[go: up one dir, main page]

Skip to content

ENH: pathlib support for fromfile(), .tofile() and .dump() #12915

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

Merged
merged 9 commits into from
Jun 4, 2019
Prev Previous commit
Next Next commit
Merge branch 'master' into pathlib_support
  • Loading branch information
eric-wieser authored May 31, 2019
commit 9a968f3e41f9f187251c489fa108e68d1ae99884
43 changes: 43 additions & 0 deletions doc/release/1.17.0-notes.rst
Original file line number Diff line number Diff line change
Expand Up @@ -318,6 +318,49 @@ Pathlib support for ``np.fromfile``, ``ndarray.tofile`` and ``ndarray.dump``
``np.fromfile``, ``np.ndarray.tofile`` and ``np.ndarray.dump`` now support
the `pathlib.Path` type for the ``file``/``fid`` parameter.

Specialized ``np.isnan``, ``np.isinf``, and ``np.isfinite`` ufuncs for bool and int types
-----------------------------------------------------------------------------------------
The boolean and integer types are incapable of storing ``np.nan`` and
``np.inf`` values, which allows us to provide specialized ufuncs that are up to
250x faster than the current approach.

``np.isfinite`` supports ``datetime64`` and ``timedelta64`` types
-----------------------------------------------------------------
Previously, `np.isfinite` used to raise a ``TypeError`` on being used on these
two types.

New keywords added to ``np.nan_to_num``
---------------------------------------
``np.nan_to_num`` now accepts keywords ``nan``, ``posinf`` and ``neginf``
allowing the user to define the value to replace the ``nan``, positive and
negative ``np.inf`` values respectively.

MemoryErrors caused by allocated overly large arrays are more descriptive
-------------------------------------------------------------------------
Often the cause of a MemoryError is incorrect broadcasting, which results in a
very large and incorrect shape. The message of the error now includes this
shape to help diagnose the cause of failure.

`floor`, `ceil`, and `trunc` now respect builtin magic methods
--------------------------------------------------------------
These ufuncs now call the ``__floor__``, ``__ceil__``, and ``__trunc__``
methods when called on object arrays, making them compatible with
`decimal.Decimal` and `fractions.Fraction` objects.

`quantile` now works on `fraction.Fraction` and `decimal.Decimal` objects
-------------------------------------------------------------------------
In general, this handles object arrays more gracefully, and avoids floating-
point operations if exact arithmetic types are used.

Support of object arrays in ``np.matmul``
-----------------------------------------
It is now possible to use ``np.matmul`` (or the ``@`` operator) with object arrays.
For instance, it is now possible to do::

from fractions import Fraction
a = np.array([[Fraction(1, 2), Fraction(1, 3)], [Fraction(1, 3), Fraction(1, 2)]])
b = a @ a


Changes
=======
Expand Down
You are viewing a condensed version of this merge commit. You can view the full changes here.
0