Numpy: np.clip mit komplexer Eingabe ist ungetestet und hat ein merkwürdiges Verhalten

Das aktuelle Verhalten ist, x = sorted(x) für x = [min, clip(arr, min, max), max] , denke ich.

Ich bezweifle, dass es wertvoll ist, die Konsistenz mit min, max zu brechen und hier nach einer nicht offensichtlichen Verhaltenswahl zu sortieren. Nicht, dass wir das nicht können, aber dann sollten wir wahrscheinlich auch über Min / Max und Sortierverhalten sprechen ...
Und wenn das heißt, dass ein absmin , absmax und abssort sinnvoll wäre und dies im Grunde genommen zum Ausschneiden verwendet.
Ich könnte leichter davon überzeugt sein, nur einen Fehler für nicht reale Eingaben zu machen.

BEARBEITEN: Vermutlich ermöglicht das komponentenweise Abschneiden tatsächlich das Erics-Verhalten, da es strenger ist. Aber nur eine Anmerkung, ich bin nicht sicher, ob ich es als nützlich kaufe. Die andere Frage ist: Gibt es überhaupt einen tatsächlichen

Real- und Imaginärteile getrennt schneiden

Das wäre meine erste Wahl.

Absolutwert abschneiden, Phase nicht ändern

Könnte nützlich sein, ist aber komplizierter zu implementieren als ein einfacher Clip.

Die andere Frage ist: Gibt es überhaupt einen tatsächlichen Fall dafür? Eine, die mit anderem Code nicht klarer ist?

Das ist eine gute Frage. Ich bin mir nicht sicher. Ich weiß nur, dass es nicht so offensichtlich falsch sein sollte.

Ich mache mir Sorgen, dass Real- und Imaginärteil getrennt abgeschnitten werden. Wenn wir beispielsweise ein sortiertes Array haben, ändert das Abschneiden das Array normalerweise so, dass es drei Regionen aufweist: [min_value, unverändert, max_value]. Wenn wir jedoch den Real- und Imaginärteil eines komplexen Arrays getrennt abschneiden, haben wir diese trennbaren Bereiche nicht mehr. Stattdessen können sich die Werte ändern, auch wenn sie nicht kleiner als das Minimum oder größer als das Maximum sind!

Ich würde auch empfehlen, das Verhalten zu deaktivieren, bis Vertrauen darüber besteht, was genau das Abschneiden einer komplexen Zahl bewirken soll. Mein Vorschlag wäre, wenn c <min_value auf min_value gesetzt ist und wenn c> max_value auf max_value gesetzt ist.

@mruberry , stimmte ich zu, auf jeden Fall bin ich mir nicht einmal sicher, ob jemand überhaupt einen Anwendungsfall dafür hatte, was mich sehr motivieren würde, irgendetwas einzubringen. Als ein Argument, um es ein bisschen weniger schlecht zu machen, wenn Sie sicherstellen, dass min.real <= max.real und min.imag <= max.imag im Gegensatz zu nur min <= max , dann sind die Dinge in Ordnung (obwohl wir dies derzeit eigentlich nicht tun Stellen Sie dies in NumPy sicher.

Ich stimme dir auch zu

Ich denke, wir werden das Abschneiden (wir nennen es Klemmen) komplexer Eingaben in PyTorch vorerst deaktivieren. Unser Verhalten stimmte sowieso nicht mit dem von NumPy überein.

Wenn ich nur diese Ausgabe durchlese, denke ich, dass dieses Verhalten angesichts des lexikografischen Vergleichs in Numpy tatsächlich Sinn macht. Wenn wir den lexikografischen Vergleich jedoch ablehnen, sollten auch clip, max und min folgen. Ich gehe davon aus, dass dies der hier erzielte Konsens war, aber ich war mir aus den Kommentaren und den verknüpften PRs nicht sehr sicher.