我看到了你的源码，你的 measure_time 函数在两次 clock_gettime() 之间只执行了一次 poly 函数，可能波动会比较大，多执行几次 poly 函数的话波动会被多次的执行均摊，测量结果会更稳定。

我放几张图就很清晰了：

原版：

执行 50 次 poly 取均值：

可以看到取均值的方法得到的数据线性化程度更好，我个人认为这足以说明这样测得的数据更可信。

题外话，可以看到图中有一些离群点，我在打分程序（main.c）中使用了 RANSAC 算法尝试减少离群点带来的影响。但实际上由于离群点数量远小于样本数量，不用 RANSAC 算法结果也已经足够令人满意（如上图所示）。

右键点击 ics-arm.dfshan.net 这一行，再点击“在当前窗口中连接”，应当就能连接了。

如果仍然不能连接，请附上你的 .ssh/config 文件的内容。

另外，新的 linker lab 用的是原来的 igw.dfshan.net 服务器，optimization lab 才需要用 ics-arm.dfshan.net 服务器，而且 optimization lab 截止日期已经过了（你仍然可以交到迟交窗口，我们会酌情处理）。

optim lab 的发布时间已经很早了，留给大家做的时间很多，不能再延期了。

pow 函数定义在 libm 中，编译命令加入-lm 即可通过。然而最终测评时使用的 Makefile 不会添加-lm，因此 pow 函数不可用，请换用不需要 pow 函数的解法。

grader 是怎么运行的：查看 Makefile 可以知道 grade 是 main.c, poly.c 和 measure_time_std.o 编译而来的，其中 measure_time_std.o 是测量执行时间的标准实现编译后的目标文件。执行 ./grade 时执行的便是 main.c 中的代码。

现象的解释：首先我没能复现出这个现象，我尝试以几种方式修改 measure_time() 函数后，要么都是 100 分要么都是 75 分。
我给出我对这一现象的原因的猜测如下：输出重定向到文件后最后一个 test 不再得分，并且测得的 CPE 都明显偏大，初步猜测是测量时间的函数没有预热 cache，而输出重定向到文件的操作比直接输出到终端要更复杂，从而使 cache miss 增加，测得的 CPE 就偏大。但这只是猜测的结论、很可能不正确，如果想进一步讨论可以将你的 measure_time() 实现私发给助教（我），我尝试复现现象之后再进行分析。

已发布