这出现在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])
对复杂输入的唯一测试是它不会存在段错误。
合理的行为可能是以下情况之一：
- 分别剪切实部和虚部
- 剪辑绝对值，不改变相位
可能还有其他选择。 只要记录在案，我不确定哪个选择重要。
我认为这不是一个非常重要的问题，但是至少在此处记录所需的行为会很好。
rgommers
所有8条评论
我认为目前的行为是将x = sorted(x)换成x = [min, clip(arr, min, max), max] 。
eric-wieser
于 2020-02-25
我怀疑打破最小值，最大值的一致性是否有价值，并在此处针对非显而易见的行为选择进行排序。 并不是说我们不能做到这一点，但是我们可能还应该讨论最小/最大和排序行为...
如果这就是说absmin ， absmax和abssort是有意义的，并且基本上将其用于剪切。
我可以更容易地说服我为非真实输入给出错误。
编辑：可以说逐分量裁剪实际上允许Erics行为，因为它更加严格。 但请注意，我不确定我是否会买到有用的东西。 另一个问题是：对此是否有实际用例？ 用不同的代码还不清楚吗？
seberg
于 2020-02-25
分别剪切实部和虚部
那将是我的第一选择。
剪辑绝对值，不改变相位
可能有用，但实现起来比简单的剪辑要复杂。
charris
于 2020-02-25
另一个问题是：对此是否有任何实际的“用例”？ 用不同的代码还不清楚吗？
这是个好问题。 我不确定。 我所知道的是，它不应该如此明显地不正确。
rgommers
于 2020-02-26
我担心分开剪切实部和虚部。 例如，如果我们有一个已排序的数组，则剪切通常会将数组更改为具有三个区域：[min_value，undefined，max_value]。 但是，如果我们分别裁剪复杂数组的实部和虚部，那么我们将不再具有这些可分离的区域。 取而代之的是，即使它们的值不小于最小值或大于最大值，值也可能会改变！
我也建议禁用该行为，直到对确切地裁剪一个复数有信心为止。 我的建议是，如果c <min_value设置为min_value，如果c> max_value设置为max_value。
mruberry
于 2020-04-10
@mruberry ，我同意，无论如何，我什至不能确定有人为此用过一个用例，这将大大激励我投入任何东西。 作为使情况变差一点的一个论据，如果您确保min.real <= max.real和min.imag <= max.imag而不是min <= max ，那么事情就好了（尽管我们目前实际上并不确保在NumPy中执行此操作）。
seberg
于 2020-04-10
我也同意你的看法，@
我认为我们现在将暂时禁用PyTorch中的复杂输入（我们称其为钳位）。 无论如何，我们的行为与NumPy的行为不一致。
mruberry
于 2020-04-10
只是阅读了这个问题，我认为给定numpy中的字典比较，这种行为实际上是有道理的。 如果我们不赞成字典比较，那么clip，max和min也应紧随其后。 我以为这是在这里达成的共识，但是从评论和链接的PR中我不太确定。
anirudh2290
于 2020-05-27
相关问题
inducer
·
3评论
Levstyle
·
3评论
MareinK
·
3评论
thouis
·
4评论
astrofrog
·
4评论
最有用的评论
@mruberry ，我同意，无论如何，我什至不能确定有人为此用过一个用例，这将大大激励我投入任何东西。 作为使情况变差一点的一个论据，如果您确保
min.real <= max.real和min.imag <= max.imag而不是min <= max，那么事情就好了（尽管我们目前实际上并不确保在NumPy中执行此操作）。