Pude rastrear este problema de github estrechamente relacionado en el repositorio numpy . Según Robert Kern , uno de los principales contribuyentes de numpy y scipy , la decisión sobre el tipo de resultado se toma en función de los tipos de entrada. numpy se basa en rutinas subyacentes que tienen implementaciones específicas de tipo en las que ambos argumentos son del mismo tipo, por lo que debe promoverse a algún tipo común. En este caso, el problema es que un tipo no está firmado y el otro está firmado:

...es una confluencia de varios factores. La implementación de numpy.add() ufunc que subyace en estas rutinas solo tiene implementaciones específicas de tipo donde los dos argumentos son del mismo tipo. Entonces, el sistema ufunc necesita convertir los argumentos en un tipo común. Uno de los argumentos está firmado, por lo que ambos argumentos deben convertirse en un tipo firmado. El tipo con signo más pequeño que puede representar valores hasta el rango máximo de uint64 es float64 (¡Nota! ¡No todos los valores de uint64 se pueden representar como float64 flotantes! ¡Se pierde precisión! Pero es mejor que int64 donde se pierde toda la mitad superior de los valores .).

Tenga en cuenta que ocurre algo similar con los tipos numpy firmados y sin firmar, np.uint y np.int :

 >>> import numpy as np >>> np.uint(0) + np.int64(1) 1.0