BUG: add type cast check for ediff1d by tylerjereddy · Pull Request #11805 · numpy/numpy (original) (raw)

Fixes #11490.

This is surprisingly tricky, because ediff1d is subject to certain constraints in the unit tests. And indeed, we'd need to be cautious with any kind of behavior change to fix that issue.

Consider test_ediff1d:

zero_elem = np.array([]) # this defaults to float64 assert_array_equal([0], ediff1d(zero_elem, to_begin=0))

np.asanyarray([0]) and np.array([0]) are int64

If I apply type checking preservation on zero_elem -> returned value there it will fail because the prepend and expected test objects are both int64. Maybe int->float promotion should be allowed but the reverse (which happens in the linked issue) prohibited?

I thought an alternative solution might be to offload type promotion handling to np.append(), but that will fail unit tests because we do sometimes check for type passthrough on the input ary object:

assert(isinstance(np.ediff1d(np.matrix(1), to_begin=1), np.matrix))

np.append(np.asanyarray(1), np.matrix(1)).dtype is 'int64' for example,

although this gives a different result too

same for: np.append(np.asanyarray(1), np.ediff1d(np.matrix(1))).dtype

here the result is closer but an array instead of matrix

I wonder why ediff1d even has those to_begin and to_end arguments--is there actually an explicit intention to have this behave differently from i.e., append() as far as type handling goes? It looks like this may be cut out for matrix handling in particular maybe?

The docstring for ediff1d isn't so clear on matters of type handling / casting / promotion as far as I can tell, and the current unit tests don't necessarily steer me toward any single clear solution so maybe I need a bit of guidance here.