Bitwise Operations on numpy.int32 and int have different result types in macOS vs Windows, but same dtype __repr__ #17351

Activity

1. BvB93 commented on Sep 19, 2020

   

   BvB93

   on Sep 19, 2020

   Last edited by BvB93

   Member

   More actions

   Some further testing shows that there are some serious inconsistencies here between integers, 0D arrays and >0D arrays:

   In [1]: import operator
      ...: from typing import Callable, Dict, Type, Any
      ...:
      ...: import numpy as np
      ...:
      ...: INT_DICT = {
      ...:     # Scalars
      ...:     'int8': np.int8(1),  # np.byte
      ...:     'int16': np.int16(1),  # np.short
      ...:     'int32': np.int32(1),  # np.int_
      ...:     'int64': np.int64(1),  # np.longlong
      ...:
      ...:     # 0D arrays
      ...:     'int8_0d': np.array(1, dtype=np.int8),
      ...:     'int16_0d': np.array(1, dtype=np.int16),
      ...:     'int32_0d': np.array(1, dtype=np.int32),
      ...:     'int64_0d': np.array(1, dtype=np.int64),
      ...:
      ...:     # 1D arrays
      ...:     'int8_1d': np.array([1], dtype=np.int8),
      ...:     'int16_1d': np.array([1], dtype=np.int16),
      ...:     'int32_1d': np.array([1], dtype=np.int32),
      ...:     'int64_1d': np.array([1], dtype=np.int64),
      ...: }
      ...:
      ...: def get_output_types(op: Callable, *args: Any) -> Dict[str, Type[np.integer]]:
      ...:     return {name: op(value, *args).dtype.type for name, value in INT_DICT.items()}
      ...:
   
   # `builtins.int` and `np.int32` exhibit identical behavior
   In [2]: get_output_types(operator.__and__, 1)
   Out[2]:
   {'int8': numpy.intc,
    'int16': numpy.intc,
    'int32': numpy.int32,
    'int64': numpy.int64,
   
    'int8_0d': numpy.intc,
    'int16_0d': numpy.intc,
    'int32_0d': numpy.intc,
    'int64_0d': numpy.int64,
   
    'int8_1d': numpy.int8,
    'int16_1d': numpy.int16,
    'int32_1d': numpy.intc,
    'int64_1d': numpy.int64}
   
   In [3]: get_output_types(operator.__and__, np.int64(1))
   Out[3]:
   {'int8': numpy.int64,
    'int16': numpy.int64,
    'int32': numpy.int64,
    'int64': numpy.int64,
   
    'int8_0d': numpy.int64,
    'int16_0d': numpy.int64,
    'int32_0d': numpy.int64,
    'int64_0d': numpy.int64,
   
    'int8_1d': numpy.int8,
    'int16_1d': numpy.int16,
    'int32_1d': numpy.intc,
    'int64_1d': numpy.int64}

   Numpy: 1.20.0.dev0+9e63ecf
   Python: 3.8.5 | packaged by conda-forge | (default, Jul 31 2020, 01:53:45) [MSC v.1916 64 bit (AMD64)]
2. BvB93

   added

   00 - Bug

   on Sep 19, 2020
3. eric-wieser commented on Sep 19, 2020

   

   eric-wieser

   on Sep 19, 2020

   Member

   More actions

   @BvB93, I'd recommend you perform your tests with the canonical char, short, intc, int_, longlong names so that you don't accidentally miss a type.
4. eric-wieser commented on Sep 19, 2020

   

   eric-wieser

   on Sep 19, 2020

   Member

   More actions

   The danger of changing dtype.__repr__ is that the array repr no longer round-trips to a platform-guaranteed memory layout. Perhaps the rarity of platforms where this matters makes this point moot.
5. BvB93 commented on Sep 19, 2020

   

   BvB93

   on Sep 19, 2020

   Last edited by BvB93

   Member

   More actions

   @BvB93, I'd recommend you perform your tests with the canonical char, short, intc, int_, longlong names so that you don't accidentally miss a type.

   Good to know, I'll keep it in mind for next time.

   Still, what I find somewhat concerning is the discrepancy between the output (d)type of >0D arrays
   versus those from 0D arrays/integers.
   EDIT: Nevermind the last part, this behavior is clearly documented in the np.result_type docs.