Numpy: np.floor_divide descarta a parte imaginária silenciosamente

Você não pode ter uma função de piso para números complexos.
Piso de Números Complexos
Além disso, não dividimos a parte imaginária e a parte complexa separadamente. Obtemos um número complexo ao dividir 2 números complexos. ( Dividindo números complexos )

Além disso ,
`>>> (1. + 1.j) // 2

Traceback (última chamada mais recente):
Arquivo "", linha 1, em
TypeError: não pode usar o andar de número complexo.

Da mesma forma, deve mostrar TypeError .
Eu sou novo no código aberto. Eu gostaria de fazer isso. Alguém pode me orientar?

O Numpy não pode usar números complexos, então, em vez de dar um erro, ele simplesmente descarta a parte imaginária. Então, acho que o Numpy está funcionando bem

Ok, achei que valeria a pena lançar pelo menos um aviso, que a parte imaginária está descartada, semelhante a outras funções.

Python normal lança um erro, parece que provavelmente deveríamos seguir o exemplo, a menos que alguém possa pensar em um caso de uso.

Sim, acho que devemos lançar um TypeError.
Posso trabalhar nisso?

Pessoalmente, eu até preferiria a (2 + 2j) // 2 = (1 + 1j), embora não seja perfeitamente correto matematicamente.

Não tenho certeza do que é melhor, o resto simplesmente não é implementado para complexos (gera um erro). E se errarmos, talvez devêssemos suspender primeiro.

Claro que você pode trabalhar nisso, será necessário mergulhar um pouco em como os ufuncs funcionam e são gerados, então pode não ser tão trivial, também pode haver alguma discussão necessária sobre aonde queremos ir. Isso não precisa impedi-lo.

"Diante da ambigüidade, recuse a tentação de adivinhar." sugere que deveria ser TypeError .

@ kaivu1999 - para resolver isso, provavelmente melhor seria remover os tipos complexos de serem gerados no floor_divide ufunc (observe que divmod , remainder e modf já estão OK). Procure em core/src/umath/loops.c.src , no material após a linha 2321 (provavelmente apenas remova as linhas 2480--2500).

@mhvk sim, você também deve ajustar numpy/core/code_generators/generate_umath.py , mas se quisermos descontinuar primeiro, você terá que criar um resolvedor de tipo personalizado provavelmente (toca adicionalmente numpy/core/src/umath/ufunc_type_resolution.c ).

@seberg - parece que o comportamento atual deveria ser considerado apenas um bug, e para consistência com remainder e divmod , devemos começar a gerar um erro.

Se queremos um comportamento diferente, pareceria uma discussão separada.

Sim, estou nisso.
Eu mudei o código, e agora mostra:
`>>> a // 2

Traceback (última chamada mais recente):
Arquivo "", linha 1, em
TypeError: ufunc 'floor_divide' não é compatível com os tipos de entrada, e as entradas não podem ser coagidas com segurança para nenhum tipo compatível de acordo com a regra de fundição '' seguro ''
`
Devo gerar a solicitação de pull?

@ kaivu1999 uma solicitação pull seria um bom começo. Certifique-se de colocar Fixes #13236 no primeiro comentário, que cruzará a referência do problema e do PR.

Fazer a divisão do chão nas partes reais e imaginárias faz algum sentido se documentarmos que os inteiros gaussianos são o resultado. Isso não seria consistente com Python.