Numpy: np.clip con entrada compleja no está probado y tiene un comportamiento extraño

El comportamiento actual es hacer x = sorted(x) por x = [min, clip(arr, min, max), max] , creo.

Dudo que sea valioso romper la coherencia con min, max, clasificando aquí para una elección de comportamiento no obvia. No es que no podamos hacerlo, pero probablemente también deberíamos discutir el comportamiento mínimo / máximo y de clasificación ...
Y si eso quiere decir que absmin , absmax y abssort tendrían sentido y básicamente lo usarían para recortar.
Podría convencerme más fácilmente de dar un error para una entrada no real.

EDITAR: Podría decirse que el recorte por componentes en realidad permite el comportamiento de Erics, ya que es más estricto. Pero solo una nota, no estoy seguro de si me parece útil. La otra pregunta es: ¿hay algún caso de uso real para esto en absoluto? ¿Uno que no es más claro con código diferente?

Clip de partes reales e imaginarias por separado

Esa sería mi primera opción.

Recortar valor absoluto, sin cambiar la fase

Podría ser útil pero es más complicado de implementar que un simple clip.

La otra pregunta es: ¿hay algún _ caso de uso_ real para esto? ¿Uno que no es más claro con código diferente?

Buena pregunta. No estoy seguro. Todo lo que sé es que no debería ser tan obviamente incorrecto.

Me preocupa recortar las partes real e imaginaria por separado. Si tenemos una matriz ordenada, por ejemplo, el recorte normalmente cambia la matriz para que tenga tres regiones: [min_value, sin cambios, max_value]. Sin embargo, si recortamos las partes real e imaginaria de una matriz compleja por separado, ya no tendremos estas regiones separables. En cambio, los valores pueden cambiar incluso si no se comparan menos que el mínimo o más que el máximo.

También recomendaría deshabilitar el comportamiento hasta que haya confianza en lo que, exactamente, debería hacer el recorte de un número complejo. Mi propuesta sería que si c <min_value se establece en min_value, y si c> max_value se establece en max_value.

@mruberry , estuve de acuerdo, en cualquier caso, ni siquiera estoy seguro de que alguien tuviera un caso de uso para esto, lo que me motivaría mucho a poner cualquier cosa. Como argumento para hacerlo un poco menos malo, si te aseguras de que min.real <= max.real y min.imag <= max.imag en lugar de solo min <= max , entonces las cosas van bien (aunque actualmente no asegúrese de esto en NumPy).

Yo también estoy de acuerdo contigo @seberg ;).

Creo que vamos a deshabilitar las entradas complejas de recorte (lo llamamos sujeción) en PyTorch por ahora. Nuestro comportamiento fue inconsistente con el de NumPy, de todos modos.

Solo leyendo este número, creo que dada la comparación lexicográfica en números, este comportamiento realmente tiene sentido. Sin embargo, si estamos desaprobando la comparación lexicográfica, también deberían seguir clip, max y min. Supongo que este fue el consenso alcanzado aquí, pero no estaba muy seguro de los comentarios y los RP vinculados.