Question

我对time.time()功能的某些行为感到有些困惑，我很好奇我是否只是无知。

好吧，所以我知道我可以解压缩并分配两个函数调用：

>>> import time
>>> beg, end = time.time(), time.time()
>>> beg == end
True

~~这种平等是有道理的，因为在执行时，第一个time.time()和第二个time.time()是相同的 - 它们在同一时间点被评估~~

更令人困惑的是：

>>> beg = time.time(); end = time.time()
>>> beg == end
True

这种平等我觉得很奇怪。我猜time.time()只能舍入到7位小数，也许Python可以在不到0.0000001秒内快速执行这两个命令（我的直觉告诉我情况就是这样）。我认为这种平等可能只是Python非常快一次，所以我尝试了很多次：

for _ in range(10000):
    beg = time.time(); end = time.time()
    assert beg == end

对我而言，这不会引发AssertionError。这笔交易是什么，在这里？ Python是否比我更快得到赞美？我的假设是; - 分开的语句连续评估，但不是同时评估（因此我感到惊讶的是beg从来没有等于end）。

编辑：

这里有time.time()为我返回的内容，以及我机器的规格：

Python 3.6.0 (v3.6.0:41df79263a11, Dec 23 2016, 07:18:10) [MSC v.1900 32 bit (Intel)] on win32
Type "copyright", "credits" or "license()" for more information.
>>> import time
>>> time.time()
1508532204.5873115
>>> time.time()
1508532250.9893117

Answer 1

首先，关于展开列表的假设是错误的。 beg, end = time.time(), time.time()可以提供不同的时间值，因为time()函数计算两次，并且可以返回单独的结果。

具体来说，Python首先构建一个包含两个时间值的元组(time.time(), time.time())。然后将该元组解包为变量beg, end。

对于paralellisation或值缓存甚至var-by-var赋值没有特殊的魔力（考虑：a,b = b,a值交换模式：它实际上是t = (b,a); (a,b) = t）。

其次，时间戳比较在很大程度上取决于您的系统（主要是OS）。

对于time.time()，无法保证细粒度分辨率：

请注意，即使时间总是作为浮点返回数字，并非所有系统都提供比1更精确的时间第二

在unix系统（非MacOSX）上，您可以尝试使用time.clock_getres(clk_id)来获取时钟分辨率。

在Windows上，似乎是你的情况，你可以找到time.clock()手册中提到的QueryPerformanceCounter()的Win32调用中的信息（我没有足够的知识来评论Windows API）。

你也应该在操作系统上谷歌时间精确度来回答这个问题，因为它与python无关。

如果分辨率不足以进行此类测量，并且CPU速度非常快（现在通常为典型值），那么时间测量将太接近而无法区分它们。当然，如果以CPU策略衡量，它们将是不同的，相距甚远。但最小可用时间单位没有差别。

要注意的是，尝试在速度慢得多的机器上执行代码，或者当CPU高度超载某些计算任务（即使用99-100％的CPU）时，不能在流程上花费太多时间。如果CPU不只是忙于一个进程，而是在多个进程之间经常切换上下文 - 例如，通过几百个CPU密集型进程或者可能有1-2千个空闲CPU（如在fork炸弹中）。

UPD：关于问题的更多详细信息：逗号后面的数字位数与机器上的时间分辨率无关，除非它不是1秒。

操作系统只测量1秒内的内容。结果不仅取决于时钟分辨率，还取决于时间请求的时间，并且可能会有所不同。

更不用说浮动精度的问题，其中分数可以不正确地舍入到最近的'＃34;拟合＆＃34;浮动。根据逗号前部分的大小来比较浮点数的精度：

>>> 2/3
0.6666666666666666

>>> 2000000/3
666666.6666666666

>>> 200000000000/3
66666666666.666664   # <== Surprise! ;-)

连续，同线函数调用与解包

1 个答案: