Python OpenCV和Numpy交互不好

有人能解释为什么导入cv和numpy会改变python的struct.unpack的行为吗？以下是我观察到的：

Python 2.7.3 (default, Aug  1 2012, 05:14:39) 
[GCC 4.6.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> from struct import pack, unpack
>>> unpack("f",pack("I",31))[0]
4.344025239406933e-44

这是正确的

>>> import cv
libdc1394 error: Failed to initialize libdc1394
>>> unpack("f",pack("I",31))[0]
4.344025239406933e-44

导入cv后仍然可以

>>> import numpy
>>> unpack("f",pack("I",31))[0]
4.344025239406933e-44

导入cv和numpy后，单击“确定”

现在我重新启动python：

Python 2.7.3 (default, Aug  1 2012, 05:14:39) 
[GCC 4.6.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> from struct import pack, unpack
>>> unpack("f",pack("I",31))[0]
4.344025239406933e-44
>>> import numpy
>>> unpack("f",pack("I",31))[0]
4.344025239406933e-44

到目前为止还不错，但现在我在导入numpy后导入cv：

>>> import cv
libdc1394 error: Failed to initialize libdc1394
>>> unpack("f",pack("I",31))[0]
0.0

我已经重复了很多次，包括在多台服务器上，而且总是以同样的方式进行。我也尝试过struct.unpack和struct.pack，这也没什么区别

我无法理解导入numpy和cv如何会对struct.unpack的输出产生任何影响（顺便说一句，pack保持不变）

“libdc1394”这件事，我相信，是一条红鲱鱼：

有什么想法吗

tl；dr：导入numpy然后导入opencv会更改struct.unpack的行为

---

更新：保罗在下面的回答表明这是可复制的。Seborg的评论表明，这与python处理次正常值的方式有关，这听起来似乎有道理。我进行了调查，但这似乎不是问题所在，因为导入之后的上下文与导入之前的上下文相同。

这不是答案，但它太大了，无法发表评论。我对这些值进行了一些调整，以找到极限

不加载

numpy

和

cv

：

>>> unpack("f", pack("i", 8388608))
(1.1754943508222875e-38,)
>>> unpack("f", pack("i", 8388607))
(1.1754942106924411e-38,)

加载

numpy

和

cv

后，第一行相同，但第二行：

>>> unpack("f", pack("i", 8388607))
(0.0,)

您会注意到第一个结果是。然后我用

d

尝试了同样的方法

在不加载库的情况下：

>>> unpack("d", pack("xi", 1048576))
(2.2250738585072014e-308,)
>>> unpack("d", pack("xi", 1048575))
(2.2250717365114104e-308,)

>>> unpack("d",pack("xi", 1048575))
(0.0,)

加载库后：

>>> unpack("d", pack("xi", 1048576))
(2.2250738585072014e-308,)
>>> unpack("d", pack("xi", 1048575))
(2.2250717365114104e-308,)

>>> unpack("d",pack("xi", 1048575))
(0.0,)

现在，第一个结果是64位浮点精度的下限

---

似乎出于某种原因，按此顺序加载

numpy

和

cv

库会限制

unpack

使用32位和64位精度，并为较低的值返回0。

这对您没有帮助，但仅仅是为了可读性和简化问题，

解包（“f”，pack（“I”，31））

产生同样的结果？@PauloAlmeida:很好。只是试过了——是的，同样的结果。。。我将编辑这个问题以使其更易于阅读…@Ben No problem:）如果您还没有测试Python 3，请进行测试，因为CV似乎会检查它并以不同的方式定义内容。另外，如果您对numpy的_uinit__uuy.py中的每一行进行注释，行为就会消失（至少在我的系统上，我做了一个快速测试），但我没有进一步调查。我认为这与低于正常的数字handleing有关。struct结果似乎已经将次正常值向上取整为最小的法定浮动/双精度（真的应该这样吗？）。我不确定CPU的舍入标志是如何工作的，但我猜CV会改变事物舍入的一些标志。当然，原因是次正常值非常慢，所以CV希望避免它们，因为出于其目的，它们可能是不必要的。我不知道为什么在整个过程中会更改这些标志，但我想这些标志并不是那么简单。@seberg--谢谢--这很有帮助。你能给我指一些关于次正常值的有用资源吗？这不是我以前遇到过的…@Ben，我被

'xi'

骗了，当然了。。。尽管如此，我还是认为这可能在某种程度上与非规范化有关。