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使用高斯核,因此所有点都具有严格的正权重.我的猜测是权重很小,但是舍入或浮点计算可能是个问题.我不知道如何解决这个问题.
> locpoly(x,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,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,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中的函数的源代码,它们看起来是一样的.但是,我确实发现这个Rounding differences on Windows vs Unix based system in sprintf显示unix和windows之间的舍入差异存在报告错误.虽然3年前曾被问过.所以我想说差异可能是操作系统或版本为KernSmooth(倾向于操作系统,因为其他人也遇到了这个问题)
