R:locpoly错误地返回NaN

Question

运行以下代码给我一个NaN:

library(KernSmooth) 
x <- c(5.84155992364115, 1.55292112974119, 0.0349665318792623, 3.93053647398094,
       3.42790577684633, 2.9715553006801, 0.837108410045353, 2.872476865277, 
       3.89232548092257, 0.206399650539628) 
y <- c(0.141415317472329, 1.34799648955049, 0.0297566221758204, 
       -0.966736679061812, 0.246306732122746, 0.557982376254723, 
       0.740542828791083, 0.162336127802977, -0.428804158514744, 
       0.691280978689863) 

locpoly(x, y, bandwidth = 0.4821232, gridsize = 12, degree = 1)[['y']]

我明白了

[1]  0.3030137  0.6456624  0.9530586  1.1121106  0.8120947  0.4441603
[7]  0.1425592 -0.3600028 -0.7840411 -1.0517612 -1.2690134        NaN

在另一台计算机上,我得到相同的,除了我-0.7270521而不是NaN.我猜大多数人也会得到这个.所以问题是如何修复破碎的系统？这与我的LAPACK或LIBBLAS有关吗？

请注意,上面提到的两台计算机都使用Ubuntu.给出了NaN使用Ubuntu 13.10的那个,给出一个数字的是12.04.

编辑:

我的新怀疑是它是一个浮点计算问题:局部多项式回归只是一个加权线性回归,其中权重越大,点越远离评估点,在这种情况下为5.84.应该注意带宽很小,所以首先想到的是带宽内没有点.然而,locpoly使用高斯核,因此所有点都具有严格的正权重.我的猜测是权重很小,但是舍入或浮点计算可能是个问题.我不知道如何解决这个问题.

Answer 1

如果我使用 Windows 7 和 R 3.0，我会得到：

 > locpoly(x, y, bandwidth = 0.4821232, gridsize = 12, degree = 1)[['y']]
 [1]  0.3030137  0.6456624  0.9530586  1.1121106  0.8120947
 [6]  0.4441603  0.1425592 -0.3600028 -0.7840411 -1.0517612
[11] -1.2690134 -2.8078788

所以你的问题不存在。但是，如果我在 Ubuntu 13.04 (GNU/Linux 3.8.0-23-generic x86_64) 上使用 R 3.0，我会得到：

 > locpoly(x, y, bandwidth = 0.4821232, gridsize = 12, degree = 1)[['y']]

 [1]  0.3030137  0.6456624  0.9530586  1.1121106  0.8120947  0.4441603
 [7]  0.1425592 -0.3600028 -0.7840411 -1.0517612 -1.2690134        NaN

我尝试进行实验，并通过使用以下方法获得了与 Windows 7 中非常相似的数字：

> locpoly(round(x,3), round(y,3), bandwidth = 0.4821232, gridsize = 12, degree = 1)[['y']]

 [1]  0.3032295  0.6459197  0.9533132  1.1121400  0.8118960  0.4437407
 [7]  0.1422658 -0.3604210 -0.7848982 -1.0531299 -1.2710219 -0.7269588

所以我希望这能够解决你的第二个问题。

为了弄清楚为什么我能够在 Windows 上得到非 NaN 答案，但在 Ubuntu 上却不行，我们可以查看http://cran.r-project.org/web/packages/KernSmooth/index.html并注意到:

MacOS X 二进制文件：KernSmooth_2.23-10.tgz Windows 二进制文件：KernSmooth_2.23-11.zip

当然有两个不同的版本，但 Windows 二进制文件比 MacOS X 二进制文件更进一步一个版本。我查看了 Ubuntu 和 Windows 中函数的源代码，它们看起来是相同的。然而，我确实在 sprintf 中发现了 Windows 与基于 Unix 的系统上的舍入差异，表明存在报告的 UNIX 和 Windows 之间舍入差异的错误。虽然这是3年前问过的。所以我想说差异可能是操作系统或 KernSmooth 的版本（会倾向于操作系统，因为其他人也遇到了这个问题）