R: locpoly 错误地返回 NaN答案

【问题标题】：R: locpoly is incorrectly returning NaNR: locpoly 错误地返回 NaN
【发布时间】：2014-03-16 05:54:16
【问题描述】：

运行以下代码会给我一个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 使用高斯核，因此所有点都具有严格的正权重。我的猜测是，尽管舍入或浮点计算可能是个问题，但权重是如此之小。我不确定如何解决这个问题。

【问题讨论】：

我也收到了NaN，正在运行 Linux。
@RScriv 感谢您的确认。我想我不是唯一一个。我也在Linux上。我在上面更新了我的操作系统信息。
我得到 NaN OSX R 3.03。现在，在我们都深入研究 LAPACK 之前，有人可以确认哪个值是“正确”的吗？
这里也一样。 OS X 10.9.2 上的 R3.0.3，我也收到了 NaN。

标签： r ubuntu lapack blas

【解决方案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 值是愚蠢的。

【讨论】：

感谢您的想法，卡尔。你有什么可以支持这种怀疑的吗？（我绝对不是说这是一个挑战，只是好奇你是否有任何见解。）你所说的“分歧”是什么意思？你让我想到了潜在的问题，我猜这是一个浮点计算问题。我将尝试用直觉将我的猜测添加到我的问题中。
@XuWang 红点（locpoly outout）的趋势明显下降，远离上次输入值。这让我相信拟合函数要么忽略要么不能“弯曲”回输入数据。
我明白你的直觉。谢谢你的解释。

【解决方案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-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 而不是 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 之间舍入差异的错误。虽然这是三年前问的。所以我想说差异可能是 KernSmooth 的操作系统或版本（会倾向于操作系统，因为其他人也遇到过这个问题）

【讨论】：

这没有回答问题。如果您使用round 但指定bandwidth = 0.3821232 问题又回来了。 round 只是有效地增加了带宽（在这个特定的例子中）。尽管如此，感谢您的努力，我认为您提供的信息最多，所以我会接受。
感谢您选择我的答案。很抱歉它没有完全回答您的问题，但这是我能做的最好的。您可以采取的最后一步是向维护软件包的 Brian Ripley 发送电子邮件。

【解决方案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，所以我没有预料到。

【讨论】：

【解决方案4】：

您要求的是 1 次局部多项式（需要 2 个点来拟合，最小值），并且 5.841559992364115 本地只有一个点。真正的问题是，为什么它没有给你一个很好的错误，告诉你增加带宽。将其微调至 0.5，一切正常。

【讨论】：

如果使用正常内核，则局部多项式回归对每个观察值加权。关键是权重非常小。但从理论上讲，这种回归是正确指定的。如需良好的参考，请阅读amazon.com/Local-Polynomial-Modelling-Its-Applications/dp/…
通常软件会添加一个切割点，超过该切割点内核设置为 0。在正常密度的情况下，4 sigma 听起来是正确的。我看不懂 FORTRAN 或 C，所以我没有查看实际函数来查看是否应用了这样的切点，但您可以使用其他示例对其进行测试。尝试将 -14、-15、-17.5、-19.5、-20.5、-21.5 添加到您的 X 和 1:6 到您的 Y，您会得到抱怨 BW 的错误。同样，这就是我在这里所期望的。

【解决方案5】：

我想换个说法，

我不是ubuntu的普通用户，但知道Java启动的NaN(Not a Number)！

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

如果某些文件丢失并且号码没有处理好。

除以零（或由于缺少库导致结果无效）可能导致结果中出现 NAN。

我不认为ubuntu有这个问题。

请指定 LAPACK 的版本以便更好地理解。（包括 Ubuntu 是 32 或 64 位，LAPACK 是 32 或 64 位）

我希望这会有所帮助。

【讨论】：

我确实怀疑除以 0，因为权重太小了。
如果它被零除，则不应在其他操作系统/系统上工作。所以我不会这么说.. :)