Numpy: np.floor_divide dépose une partie imaginaire en silence

Vous ne pouvez pas avoir de fonction de plancher pour les nombres complexes.
Plancher de nombres complexes
De plus, nous ne divisons pas la partie imaginaire et la partie complexe séparément. Nous obtenons un nombre complexe en divisant 2 nombres complexes. ( Division des nombres complexes )

Également ,
`>>> (1. + 1.j) // 2

Traceback (dernier appel le plus récent):
Fichier "", ligne 1, dans
TypeError: impossible de prendre la parole sur un nombre complexe.

De même, il devrait afficher TypeError .
Je suis nouveau sur Open Source. J'aimerais le faire. Quelqu'un peut-il me guider?

Numpy ne peut pas prendre en charge les nombres complexes, donc au lieu de donner une erreur, il laisse simplement tomber la partie imaginaire.Je pense donc que Numpy fonctionne bien

Ok, j'ai pensé qu'il vaudrait la peine de lancer au moins un avertissement, que la partie imaginaire est abandonnée, similaire à d'autres fonctions.

Un python normal génère une erreur, il semble que nous devrions probablement emboîter le pas, à moins que quelqu'un ne puisse penser à un cas d'utilisation?

Ouais, je pense que nous devrions lancer une TypeError.
Puis-je travailler dessus?

Personnellement, je préférerais même un (2 + 2j) // 2 = (1 + 1j), même si ce n'est pas parfaitement mathématiquement correct.

Je ne sais pas ce qui est le mieux, le reste n'est tout simplement pas implémenté pour les complexes (génère une erreur). Et si nous nous trompons, peut-être devrions-nous d'abord abandonner.

Bien sûr, vous pouvez travailler dessus, cela nécessitera de plonger un peu dans la façon dont les ufuncs fonctionnent et sont générés, donc ce n'est peut-être pas tout à fait trivial, il peut également y avoir une discussion nécessaire sur où nous voulons aller. Cela n'a cependant pas besoin de vous arrêter.

"Face à l'ambiguïté, refusez la tentation de deviner." suggère que ce devrait être un TypeError .

@ kaivu1999 - pour résoudre ce problème, le mieux serait probablement de supprimer les types complexes même générés dans floor_divide ufunc (notez que divmod , remainder , et modf sont déjà OK). Regardez dans core/src/umath/loops.c.src , dans les trucs après la ligne 2321 (supprimez probablement les lignes 2480-2500).

@mhvk ouais, vous devez également ajuster numpy/core/code_generators/generate_umath.py , mais si nous voulons d'abord abandonner, vous devrez probablement créer un résolveur de type personnalisé (touche en plus numpy/core/src/umath/ufunc_type_resolution.c ).

@seberg - il semble que le comportement actuel devrait vraiment être considéré comme un bogue, et que par cohérence avec remainder et divmod , nous devrions commencer à générer une erreur.

La question de savoir si nous voulons un comportement différent semblerait une discussion distincte.

Ouais, je suis dessus.
J'ai changé le code tel, et maintenant il montre:
`>>> a // 2

Traceback (dernier appel le plus récent):
Fichier "", ligne 1, dans
TypeError: ufunc 'floor_divide' non pris en charge pour les types d'entrée, et les entrées n'ont pas pu être forcées en toute sécurité à des types pris en charge selon la règle de conversion `` safe ''
»
Dois-je générer la pull request?

@ kaivu1999 une pull request serait un bon début. Veuillez vous assurer de mettre Fixes #13236 dans le premier commentaire, qui fera référence au problème et au PR.

Faire une division de plancher sur des parties réelles et imaginaires a du sens si nous documentons que les entiers gaussiens sont le résultat. Cela ne serait pas cohérent avec Python.