`.dtype.type` class object is not preserved over some operations

import numpy as np

for dt in (np.uint8, np.uint16, np.uint32, np.uint64,
           np.int8, np.int16, np.int32, np.int64,
           np.float16, np.float32, np.float64):
    x = np.array([0, 1], dtype=dt)
    if np.issubdtype(dt, np.floating):
        y = np.finfo(dt).max - x
    else:
        y = np.iinfo(dt).max - x

    id_x = hex(id(x.dtype.type))
    id_y = hex(id(y.dtype.type))

    print('{}: {}, {}, {}'.format(dt, id_x, id_y, id_x == id_y))

<class 'numpy.uint8'>: 0x7fa0e529f740, 0x7fa0e529f740, True
<class 'numpy.uint16'>: 0x7fa0e529f5a0, 0x7fa0e529f5a0, True
<class 'numpy.uint32'>: 0x7fa0e529f400, 0x7fa0e529f400, True
<class 'numpy.uint64'>: 0x7fa0e529f260, 0x7fa0e529f0c0, False
<class 'numpy.int8'>: 0x7fa0e529ff60, 0x7fa0e529ff60, True
<class 'numpy.int16'>: 0x7fa0e529fdc0, 0x7fa0e529fdc0, True
<class 'numpy.int32'>: 0x7fa0e529fc20, 0x7fa0e529fc20, True
<class 'numpy.int64'>: 0x7fa0e529fa80, 0x7fa0e529f8e0, False
<class 'numpy.float16'>: 0x7fa0e529ef20, 0x7fa0e529ef20, True
<class 'numpy.float32'>: 0x7fa0e529ed80, 0x7fa0e529ed80, True
<class 'numpy.float64'>: 0x7fa0e529ebe0, 0x7fa0e529ebe0, True

This could lead to some issues in users code heavily relying on dtype.type comparison (e.g. https://github.com/scikit-image/scikit-image/issues/3043).

Linux, x64, numpy 1.14.2.

[seberg]

Yeah, the bug is that it falls to the unsigned path, and that fallback does not convert the original typenum to its unsigned version, but instead always uses ulonglong. If you use .min instead of max, it works 😉.

[eric-wieser]

Just fired up WSL with numpy 1.11 (!), and I think I can pinpoint the bug:

assert np.result_type(np.iinfo(np.int64).max, np.int64).type is np.int64  # fails
assert np.result_type(np.iinfo(np.longlong).max, np.longlong).type is np.longlong # passes

In my opinion, we should swap between these which one passes and which fails.

We’re being inconsistent about when we pick long and when we pick long long for int64 on linux. By name, long takes precedence - but it seems that when assigning dtypes to scalars based on their value, we prefer long long.

On windows, it seems we handle int vs long for int32 consistently.