Numpy: np.clip avec une entrée complexe n'est pas testé et a un comportement étrange

Le comportement actuel est de faire x = sorted(x) pour x = [min, clip(arr, min, max), max] , je pense.

Je doute qu'il soit utile de rompre la cohérence avec min, max, en triant ici pour un choix de comportement non évident. Non pas que nous ne pouvons pas le faire, mais que nous devrions probablement également discuter du comportement min / max et du tri ...
Et si cela veut dire qu'un absmin , absmax et abssort aurait un sens et l'utiliserait essentiellement pour le découpage.
Je pourrais être plus facilement convaincu de simplement donner une erreur pour une entrée non réelle.

EDIT: On peut soutenir que l'écrêtage par composant permet en fait le comportement d'Erics, car il est plus strict. Mais juste une note, je ne suis pas sûr de l'acheter comme étant utile. L'autre question est: est - il usecase réel pour cela du tout? Un qui n'est pas plus clair avec un code différent?

Découpez séparément les parties réelles et imaginaires

Ce serait mon premier choix.

Valeur absolue du clip, sans changement de phase

Cela pourrait être utile mais il est plus compliqué à mettre en œuvre qu'un simple clip.

L'autre question est: y a-t-il un véritable cas d'utilisation pour cela? Un qui n'est pas plus clair avec un code différent?

C'est une bonne question. Je ne suis pas sûr. Tout ce que je sais, c'est que cela ne devrait pas être si manifestement incorrect.

Je crains de couper séparément les parties réelles et imaginaires. Si nous avons un tableau trié, par exemple, le découpage change généralement le tableau pour avoir trois régions: [min_value, inchangé, max_value]. Cependant, si nous découpons séparément les parties réelle et imaginaire d'un tableau complexe, nous n'aurons plus ces régions séparables. Au lieu de cela, les valeurs peuvent changer même si elles ne comparent pas moins que le min ou plus que le max!

Je recommanderais également de désactiver le comportement jusqu'à ce qu'il y ait confiance sur ce que doit faire exactement l'écrêtage d'un nombre complexe. Ma proposition serait que si c <min_value il est défini sur min_value, et si c> max_value, il est défini sur max_value.

@mruberry , j'ai accepté, en tout cas je ne suis même pas sûr que quiconque ait même un cas d'utilisation pour cela, ce qui me motiverait grandement à mettre quoi que ce soit. Comme argument pour le rendre un peu moins mauvais, si vous vous assurez que min.real <= max.real et min.imag <= max.imag par opposition à seulement min <= max , alors tout va bien (bien que nous ne le fassions pas actuellement) assurez-vous cela dans NumPy).

Je suis d'accord avec vous aussi @seberg ;).

Je pense que nous allons désactiver les entrées complexes de clipping (nous l'appelons clamping) dans PyTorch pour le moment. Notre comportement était de toute façon incompatible avec celui de NumPy.

juste en lisant ce numéro, je pense que compte tenu de la comparaison lexicographique dans numpy, ce comportement a du sens. si nous déconseillons la comparaison lexicographique, clip, max et min devraient également suivre. Je suppose que c'était le consensus atteint ici, mais je n'étais pas très sûr des commentaires et des PR liés.