Numpy: np.clip com entrada complexa não foi testado e tem comportamento estranho

O comportamento atual é fazer x = sorted(x) por x = [min, clip(arr, min, max), max] , eu acho.

Duvido que seja valioso quebrar a consistência com min, max, classificação aqui para uma escolha de comportamento não óbvia. Não que não possamos fazer isso, mas provavelmente também deveríamos discutir o comportamento de classificação mínimo / máximo ...
E se isso quer dizer que absmin , absmax e abssort fariam sentido e basicamente usariam isso para recorte.
Eu poderia ser mais facilmente convencido a apenas dar um erro por uma entrada não real.

EDITAR: Provavelmente o recorte de componentes na verdade permite o comportamento de Eric, uma vez que é mais estrito. Mas apenas uma nota, não tenho certeza se considero útil. A outra questão é: existe alguma usecase real para isso, afinal? Um que não fica mais claro com um código diferente?

Recorte partes reais e imaginárias separadamente

Essa seria minha primeira escolha.

Valor absoluto do clipe, sem alterar a fase

Pode ser útil, mas é mais complicado de implementar do que um simples clipe.

A outra pergunta é: existe algum _usecase_ real para isso? Um que não fica mais claro com um código diferente?

Esta é uma boa pergunta. Não tenho certeza. Tudo que sei é que não deveria ser tão obviamente incorreto.

Estou preocupado em cortar as partes reais e imaginárias separadamente. Se tivermos um array ordenado, por exemplo, então o recorte normalmente altera o array para ter três regiões: [min_value, unchanged, max_value]. Se cortarmos as partes reais e imaginárias de uma matriz complexa separadamente, entretanto, não teremos mais essas regiões separáveis. Em vez disso, os valores podem mudar mesmo se não compararem menos do que o mínimo ou maior do que o máximo!

Eu também recomendaria desativar o comportamento até que haja confiança sobre o que, exatamente, recortar um número complexo deve fazer. Minha proposta seria que se c <min_value fosse definido como min_value, e se c> max_value fosse definido como max_value.

@mruberry , concordei, de qualquer forma, nem tenho certeza se alguém tinha um caso de uso para isso, o que me motivaria muito a fazer qualquer coisa. Como um argumento para torná-lo um pouco menos ruim, se você garantir que min.real <= max.real e min.imag <= max.imag em oposição a apenas min <= max , então as coisas estão bem (embora atualmente não garanta isso em NumPy).

Também estou concordando com você @seberg ;).

Acho que vamos desabilitar o recorte (nós o chamamos de grampeamento) entradas complexas no PyTorch por enquanto. Nosso comportamento era inconsistente com o do NumPy, de qualquer maneira.

só de ler esta edição, acho que, dada a comparação lexicográfica em numpy, esse comportamento realmente faz sentido. se estamos descontinuando a comparação lexicográfica, porém, clip, max e min também devem seguir. Estou presumindo que esse foi o consenso alcançado aqui, mas não estava muito certo a partir dos comentários e dos PRs vinculados.