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

不是答案，但想发布图表。我仍然不清楚你期望从locpoly得到什么，但现在是。

Rgames> foo<-locpoly(x, y, bandwidth = 0.4821232, gridsize = 12, degree = 1)
Rgames> foo
$x
 [1] 0.03496653 0.56283866 1.09071078 1.61858291 2.14645504 2.67432716
 [7] 3.20219929 3.73007142 4.25794354 4.78581567 5.31368780 5.84155992

$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

我怀疑最右边的最后一点与使用中的拟合参数有所不同，而且在任何操作系统下你都获得了非NaN值，这是一种愚蠢的运气。

Answer 2

如果我使用的是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-通用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而不是Ubuntu获得非NaN答案，我们可以查看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中的函数的源代码，它们看起来是一样的。但是，我确实发现这个Rounding differences on Windows vs Unix based system in sprintf显示unix和windows之间的舍入差异存在报告错误。虽然3年前曾被问过。所以我想说差异可能是操作系统或版本为KernSmooth（倾向于操作系统，因为其他人也遇到了这个问题）

Answer 3

我使用的是Windows 7，R 3.0.1。

它似乎是一个浮点问题，但由于max(x)：从x更改max中的第一个条目（恰好是5.84155992364115）至5.841559923 NaN变为Inf，5.84155992 NaN变为-0.7261049。

同时将选项truncate设置为FALSE会大大改变输出：

locpoly(x, y, bandwidth = 0.4821232, gridsize = 12, degree = 1, truncate=F)[['y']]
[1]  0.3030137  0.6456624  0.9530586  1.1121106  0.8120947  0.4441603  0.1425592 -0.3600028 -0.7449278 -0.3872891 -0.1235228  0.1414153

我没有预料到，因为你没有指定range.x。

Answer 4

你要求的是1次局部多项式（需要2点拟合，最小值），并且只有一个点位于5.84155992364115。真正的问题是，为什么它没有给你一个很好的错误告诉你提高带宽。将其推高至0.5，这一切都有效。

Answer 5

我想换一点说，

我不是ubuntu的常用用户，但是知道由Java启动的NaN（非数字）！

首先我会说更新Lapack 并确保所有文件都已正确安装（Recent Bug）

如果某个文件丢失且编号处理不当。

除以零（或由于缺少库而导致的无效结果）可能导致结果为NAN。

我不认为ubuntu对此有任何问题。

请从更好的理解中指定LAPACK的版本。（包括Ubuntu为32或64位，LAPACK为32或64位）

我希望这会有所帮助。