Это появилось в https://github.com/pytorch/pytorch/issues/33568. Это кажется странным:
>>> np.clip([3 + 4.j], -1, 2)
array([2.+0.j])
>>> np.clip([3 + 4.j], -1+1.j, 2+12.j) # imaginary component goes up
array([2.+12.j])
>>> np.clip([1 + 4.j], -1+1.j, 2+12.j) # imaginary component doesn't go up
array([1.+4.j])
Единственный тест для сложного ввода - это отсутствие сбоев.
Разумное поведение может быть одним из:
Я не думаю, что это очень важная проблема, но было бы неплохо, по крайней мере, документировать здесь желаемое поведение.
Я думаю, что текущее поведение - сделать x = sorted(x)
за x = [min, clip(arr, min, max), max]
.
Я сомневаюсь, что здесь полезно нарушить согласованность с помощью min, max, сортировки для неочевидного выбора поведения. Не то чтобы мы не могли этого сделать, но мы, вероятно, также должны обсудить минимальное / максимальное значение и поведение сортировки ...
И если это означает, что absmin
, absmax
и abssort
имели бы смысл и в основном использовали бы это для обрезки.
Меня было бы легче убедить, что я просто выдал ошибку из-за ненастоящего ввода.
РЕДАКТИРОВАТЬ: возможно, покомпонентное отсечение фактически допускает поведение Erics, поскольку оно более строгое. Но просто примечание, я не уверен, что куплю это как полезное. Другой вопрос: есть ли вообще какой-то реальный вариант использования этого? Тот, что не понятнее с другим кодом?
Отдельно вырезать реальные и мнимые части
Это был бы мой первый выбор.
Абсолютное значение клипа, без изменения фазы
Может быть полезно, но реализовать его сложнее, чем простой зажим.
Другой вопрос: существует ли вообще какой-нибудь _usecase_ для этого? Тот, что не понятнее с другим кодом?
Это хороший вопрос. Я не уверен. Все, что я знаю, это не должно быть настолько очевидно неправильным.
Я беспокоюсь об отсечении реальной и воображаемой частей по отдельности. Например, если у нас есть отсортированный массив, то при отсечении обычно в массиве появляются три области: [min_value, unchanged, max_value]. Однако если мы отсечем реальную и мнимую части сложного массива по отдельности, то у нас больше не будет этих разделяемых областей. Вместо этого значения могут измениться, даже если они не сравниваются меньше минимального или больше максимального!
Я также рекомендовал бы отключить это поведение до тех пор, пока не появится уверенность в том, что именно должно делать вырезание комплексного числа. Мое предложение заключалось в том, что если c <min_value, он установлен на min_value, а если c> max_value, он установлен на max_value.
@mruberry , я согласился, в любом случае я даже не уверен, что у кого-то есть хотя бы вариант использования для этого, который будет иметь большое значение, чтобы мотивировать меня что-то вставлять. В качестве одного аргумента, чтобы сделать его немного менее плохим, если вы убедитесь, что min.real <= max.real
и min.imag <= max.imag
а не только min <= max
, то все в порядке (хотя в настоящее время мы не убедитесь в этом в NumPy).
Я тоже с тобой согласен @seberg ;).
Я думаю, что мы собираемся отключить отсечение (мы называем это закреплением) сложных входов в PyTorch. В любом случае, наше поведение не соответствовало поведению NumPy.
просто читая этот выпуск, я думаю, что, учитывая лексикографическое сравнение в numpy, такое поведение действительно имеет смысл. если мы отказываемся от лексикографического сравнения, также должны следовать clip, max и min. Я предполагаю, что это был достигнутый здесь консенсус, но я не был уверен в комментариях и связанных PR.
Самый полезный комментарий
@mruberry , я согласился, в любом случае я даже не уверен, что у кого-то есть хотя бы вариант использования для этого, который будет иметь большое значение, чтобы мотивировать меня что-то вставлять. В качестве одного аргумента, чтобы сделать его немного менее плохим, если вы убедитесь, что
min.real <= max.real
иmin.imag <= max.imag
а не толькоmin <= max
, то все в порядке (хотя в настоящее время мы не убедитесь в этом в NumPy).