Numpy: np.floor_divide静默丢弃虚部

复数不能使用下限功能。
复数层
此外，我们不会将虚部和复杂部分分开划分。 我们将2个复数相除得到一个复数。 （除以复数）

还有，
`>>>（1. + 1.j）// 2

追溯（最近一次通话）：
文件““，第1行，在
TypeError：不能占用复数。

类似地，它应该显示TypeError 。
我是开源的新手。 我想做。 有人可以指导我吗？

Numpy不能接受复数的底限，因此它没有给出错误，而是只是丢弃了虚部。所以我认为Numpy运作良好

好的，我认为值得提起一个警告，即虚部已被删除，这与其他功能类似。

普通的python会引发错误，似乎我们应该效仿，除非有人能想到用例？

是的，我认为我们应该抛出TypeError。
我可以处理吗？

我个人甚至更喜欢（2 + 2j）// 2 =（1 + 1j），尽管这在数学上并不完全正确。

不确定什么是最好的，剩余部分根本无法实现复杂（抛出错误）。 如果我们出错了，也许我们应该先弃用。

当然，您可以进行操作，它需要深入研究ufuncs的工作原理和生成方式，因此它可能并不简单，也可能需要对我们要去的地方进行一些讨论。 但这并不需要阻止您。

“面对模棱两可，拒绝猜测的诱惑。” 建议它应该是TypeError 。

@ kaivu1999-要解决此问题，可能最好是甚至从floor_divide ufunc中删除复杂类型（请注意， divmod ， remainder和modf已经可以）。 在core/src/umath/loops.c.src 2321行中的

@mhvk是的，您还必须调整numpy/core/code_generators/generate_umath.py ，但是如果我们要首先弃用，则可能必须创建一个自定义类型的解析器（还需要触摸numpy/core/src/umath/ufunc_type_resolution.c ）。

@seberg-似乎实际上应该将当前行为视为一个错误，并且为了与remainder和divmod ，我们应该开始引发错误。

我们是否想要不同的行为似乎是一个单独的讨论。

是的，我在上面。
我已经更改了这样的代码，现在它显示：
`>>> a // 2

追溯（最近一次通话）：
文件““，第1行，在
TypeError：输入类型不支持ufunc'floor_divide'，并且根据强制转换规则“ safe”，无法将输入安全地强制转换为任何受支持的类型
`
我应该生成拉取请求吗？

@ kaivu1999拉请求将是一个好的开始。 请确保在第一条评论中放入Fixes #13236 ，这将交叉引用该问题和PR。

如果我们证明高斯整数是结果，那么对实部和虚部进行地板除法就很有意义。 不过，这与Python并不一致。