issues: 808558647

This data as json

id node_id number title user state locked assignee milestone comments created_at updated_at closed_at author_association active_lock_reason draft pull_request body reactions performed_via_github_app state_reason repo type
808558647 MDExOlB1bGxSZXF1ZXN0NTczNTc5NzUx 4911 Fix behaviour of min_count in reducing functions 367900 closed 0     6 2021-02-15T13:53:34Z 2021-02-19T08:12:39Z 2021-02-19T08:12:02Z CONTRIBUTOR   0 pydata/xarray/pulls/4911

The first commit modifies existing tests to check Dask-backed arrays are not computed. It also adds some specific checks that the correct result (NaN or a number as appropriate) is returned and some tests for checking membership of xarray.core.dtypes.NAT_TYPES. After this commit I get 89 test failures, and they seem to cover the cases reported in #4898.

The second commit fixes these failures:

  • The checks of the nan mask in xarray.core.nanops._maybe_null_out are changed to use np.where which allows lazy evaluation.

  • Previously, xarray.core.dtypes.NAT_TYPES was a tuple of datetime64 and timedelta64 instances; I've changed it to a set of the dtypes of these instances. It is only used for the membership check in _maybe_null_out so a set seems appropriate. The previous use of instances rather than dtypes caused a bug -- np.float64 in NAT_TYPES returned true even though it only contained datetime64/timedelta64. This meant that reducing operations over all axes (axis=None or ...) with float64 arrays ignored min_count as the membership check in _maybe_null_out caused it to be skipped.

  • [x] Closes #4898

  • [x] Tests added
  • [x] Passes pre-commit run --all-files
  • [x] User visible changes (including notable bug fixes) are documented in whats-new.rst
 
{
    "url": "https://api.github.com/repos/pydata/xarray/issues/4911/reactions",
    "total_count": 0,
    "+1": 0,
    "-1": 0,
    "laugh": 0,
    "hooray": 0,
    "confused": 0,
    "heart": 0,
    "rocket": 0,
    "eyes": 0
}
     13221727 pull

Links from other tables