Numpy: np.floor_divide deja caer la parte imaginaria silenciosamente

No puede tener una función de piso para números complejos.
Piso de números complejos
Además, no dividimos la parte imaginaria y la parte compleja por separado. Obtenemos un número complejo al dividir 2 números complejos. ( División de números complejos )

También ,
`>>> (1. + 1.j) // 2

Rastreo (llamadas recientes más última):
Archivo "", línea 1, en
TypeError: no se puede tomar la palabra de un número complejo.

De manera similar, debería mostrar TypeError .
Soy nuevo en Open Source. Me gustaría hacerlo. ¿Alguien puede guiarme?

Numpy no puede tomar el piso de números complejos, así que en lugar de dar un error, simplemente deja caer la parte imaginaria, así que creo que Numpy está funcionando bien

Ok, pensé que valdría la pena lanzar al menos una advertencia, que la parte imaginaria se descarta, similar a otras funciones.

Python normal arroja un error, parece que probablemente deberíamos seguir su ejemplo, a menos que alguien pueda pensar en un caso de uso.

Sí, creo que deberíamos lanzar un TypeError.
¿Puedo trabajar en eso?

Personalmente, incluso preferiría a (2 + 2j) // 2 = (1 + 1j), aunque no es perfectamente matemáticamente correcto.

No estoy seguro de qué es lo mejor, el resto simplemente no se implementa para complejos (arroja un error). Y si cometemos un error, tal vez deberíamos desaprobar primero.

Por supuesto que puede trabajar en él, requerirá sumergirse un poco en cómo funcionan y se generan los ufuncs, por lo que puede que no sea del todo trivial, también puede ser necesario discutir un poco a dónde queremos ir. Sin embargo, eso no tiene por qué detenerte.

"Frente a la ambigüedad, rechace la tentación de adivinar". sugiere que debería ser TypeError .

@ kaivu1999 - para abordar esto, probablemente lo mejor sería eliminar los tipos complejos para que no se generen en el floor_divide ufunc (tenga en cuenta que divmod , remainder y modf ya están bien). Busque en core/src/umath/loops.c.src , en las cosas que siguen a la línea 2321 (probablemente elimine las líneas 2480--2500).

@mhvk sí, también tienes que ajustar numpy/core/code_generators/generate_umath.py , pero si queremos desaprobar primero, probablemente tendrás que crear un resolutor de tipo personalizado (toca adicionalmente numpy/core/src/umath/ufunc_type_resolution.c ).

@seberg : parece que el comportamiento actual debería considerarse un error, y que para mantener la coherencia con remainder y divmod , deberíamos empezar a generar un error.

Si podríamos querer un comportamiento diferente parecería una discusión separada.

Sí, estoy en eso.
He cambiado el código tal, y ahora muestra:
`>>> a // 2

Rastreo (llamadas recientes más última):
Archivo "", línea 1, en
TypeError: ufunc 'floor_divide' no es compatible con los tipos de entrada, y las entradas no se pueden convertir de forma segura a ningún tipo compatible de acuerdo con la regla de conversión '' segura ''
'
¿Debo generar la solicitud de extracción?

@ kaivu1999 una solicitud de extracción sería un buen comienzo. Asegúrese de poner Fixes #13236 en el primer comentario, que hará referencia cruzada al problema y al PR.

Hacer la división de piso tanto en partes reales como imaginarias tiene algún sentido si documentamos que el resultado son enteros gaussianos. Sin embargo, eso no sería consistente con Python.