Estoy un poco decepcionado de que np.inf // 2 se evalúe como np.nan y no como np.inf , como es el caso de la división normal.
¿Hay alguna razón por la que me esté perdiendo por qué nan es una mejor opción que inf ?
El infinito no es un número. Por ejemplo, ni siquiera puedes decir que infinito: infinito es cero. Entonces, se encontrará con limitaciones como esta porque NumPy es un paquete matemático numérico . Sugiero usar un paquete matemático simbólico como SymPy que puede manejar muchas expresiones diferentes usando infinito:
import sympy as sp sp.floor(sp.oo/2) sp.oo - 1 sp.oo + sp.ooVoy a ser la persona quesolo señale la implementación del nivel C sin ningún intento de explicar la intención o la justificación:
*mod = fmod(vx, wx); div = (vx - *mod) / wx; Parece que para calcular divmod para flotadores (que se llama cuando acaba dehacer una división de piso ), primero calcula el módulo y el float('inf') %2 solo tiene sentido que sea NaN , por lo que cuando calcula vx - mod termina con NaN por lo que todo se propaga nan el resto del camino.
En resumen, dado que la implementación de la división del piso usa el módulo en el cálculo y ese es NaN , el resultado de la división del piso también termina siendo NaN .
La división de piso se define en relación con el módulo, y ambos forman parte de la operación divmod.
Operaciones aritméticas binarias
Los operadores de división de piso y módulo están conectados por la siguiente identidad:
x == (x//y)*y + (x%y). La división de piso y el módulo también están conectados con la función integrada divmod():divmod(x, y) == (x//y, x%y).
Esta equivalencia no se puede mantener para x = inf — el resto inf % y no está definido — lo que hace que inf // y sea ambiguo. Esto significa que nan es al menos un resultado tan bueno como inf . Para simplificar, CPython en realidad solo implementa divmod y obtiene tanto // como % eliminando una parte del resultado ; esto significa que // hereda nan de divmod.