Numpy: np.floor_divide lässt den Imaginärteil lautlos fallen

Sie können keine Floor-Funktion für komplexe Zahlen haben.
Etage komplexer Zahlen
Außerdem teilen wir den Imaginärteil und den komplexen Teil nicht getrennt. Wir erhalten eine komplexe Zahl, wenn wir zwei komplexe Zahlen teilen. ( Komplexe Zahlen teilen )

Ebenfalls ,
`>>> (1. + 1.j) // 2

Traceback (letzter Anruf zuletzt):
Datei "", Zeile 1, in
TypeError: Kann die komplexe Zahl nicht erfassen. "

Ähnlich sollte TypeError angezeigt werden .
Ich bin neu bei Open Source. Ich würde es gerne machen. Kann mich jemand führen?

Numpy kann komplexe Zahlen nicht erfassen. Statt einen Fehler zu machen, wird einfach der Imaginärteil gelöscht. Ich denke, Numpy funktioniert gut

Ok, ich dachte, es wäre wert, zumindest eine Warnung zu werfen, dass der Imaginärteil fallen gelassen wird, ähnlich wie bei anderen Funktionen.

Normale Python wirft einen Fehler, scheint, wir sollten wahrscheinlich nachziehen, es sei denn, jemand kann sich einen Anwendungsfall vorstellen?

Ja, ich denke wir sollten einen TypeError werfen.
Kann ich daran arbeiten?

Persönlich würde ich sogar ein (2 + 2j) // 2 = (1 + 1j) bevorzugen, obwohl es mathematisch nicht perfekt korrekt ist.

Nicht sicher, was am besten ist, Rest ist einfach nicht für komplexe implementiert (wirft einen Fehler). Und wenn wir einen Fehler machen, sollten wir vielleicht zuerst ablehnen.

Natürlich können Sie daran arbeiten, es wird erforderlich sein, ein wenig in die Funktionsweise und Generierung von Ufuncs einzutauchen, so dass dies möglicherweise nicht ganz trivial ist. Außerdem ist möglicherweise noch eine Diskussion darüber erforderlich, wohin wir wollen. Das muss dich aber nicht aufhalten.

"Lehnen Sie angesichts der Zweideutigkeit die Versuchung ab, zu raten." schlägt vor, dass es ein TypeError .

@ kaivu1999 - beheben , ist es wahrscheinlich am besten, die komplexen Typen nicht mehr im floor_divide ufunc zu generieren (beachten Sie, dass divmod , remainder und modf sind schon OK). Schauen Sie in core/src/umath/loops.c.src , in Sachen, die der Zeile 2321 folgen (wahrscheinlich entfernen Sie einfach die Zeilen 2480-2500).

@mhvk Ja, Sie müssen auch numpy/core/code_generators/generate_umath.py anpassen, aber wenn wir zuerst veralten möchten, müssen Sie wahrscheinlich einen benutzerdefinierten Resolver erstellen (berührt zusätzlich numpy/core/src/umath/ufunc_type_resolution.c ).

@seberg - es scheint, dass das gegenwärtige Verhalten wirklich nur als Fehler betrachtet werden sollte, und dass wir aus remainder und divmod einen Fehler auslösen sollten.

Ob wir ein anderes Verhalten wollen, scheint eine separate Diskussion zu sein.

Ja, ich bin dabei.
Ich habe den Code so geändert, und jetzt zeigt es:
`>>> a // 2

Traceback (letzter Anruf zuletzt):
Datei "", Zeile 1, in
TypeError: ufunc 'floor_divide' wird für die Eingabetypen nicht unterstützt, und die Eingaben konnten gemäß der Casting-Regel '' safe '' nicht sicher zu unterstützten Typen gezwungen werden.
`
Soll ich die Pull-Anfrage generieren?

@ kaivu1999 eine Pull-Anfrage wäre ein guter Anfang. Bitte stellen Sie sicher, dass Fixes #13236 in den ersten Kommentar eingefügt wird, der auf das Problem und die PR verweist.

Eine Bodenteilung sowohl für Real- als auch für Imaginärteile ist sinnvoll, wenn wir dokumentieren, dass Gaußsche Ganzzahlen das Ergebnis sind. Das würde allerdings nicht mit Python übereinstimmen.