Skip to content

ediff1d with np.nan in to_begin/to_end, behaviour and error messages #13103

@stuartarchibald

Description

@stuartarchibald

Making #12713 (comment) into an issue...

Patch #12713 will cause an exception to be raised in the case of a NaN in the to_begin/to_end arrays. Numba unit tests caught this change when updating to support 1.16 series numba/numba#3826.

Reproducing code example:

import numpy as np
dt=np.float64
np.ediff1d(np.arange(10, dtype=dt), to_begin=np.array([1, np.nan], dtype=dt))

Error message:

ValueError: cannot convert 'to_begin' to array with dtype 'dtype('float64')' as required for input ary

because of lines like this with an equality test of array == array: https://github.com/numpy/numpy/pull/12713/files#diff-9e06c7b7bcc8e8153f5c2df57283b4cbR109

Further...

The error message is perhaps a bit strange in the context of e.g.:

np.ediff1d(np.arange(10, dtype=np.float32), to_begin=np.array([np.finfo(np.float64).max], dtype=np.float64)) 

which produces

ValueError: cannot convert 'to_begin' to array with dtype 'dtype('float32')' as required for input ary

which is not actually the problem, because technically the array np.array([np.finfo(np.float64).max], dtype=np.float64)) can be converted to a np.float32 dtype:

In [18]: np.array([np.finfo(np.float64).max], dtype=np.float64).astype(np.float32)                                              
Out[18]: array([inf], dtype=float32)

it's just that it's not "safe" under the given behavioural assumptions?

Happy to create a patch for either of these if considered a problem? Else Numba will be patched to match.

Thanks!

Numpy/Python version information:

$ python -c 'import sys, numpy; print(numpy.__version__, sys.version)' 
1.16.2 3.7.2 (default, Dec 29 2018, 06:19:36) 
[GCC 7.3.0]

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions