spatstat的K，F和G功能不均匀的异常行为

Question

我有大约84,000点的点阵。 Quadrat测试表明我尝试了不同的内核带宽时强度不均匀，并且在K函数，F函数和G函数的不均匀实现中得到了非常奇怪的行为。这是inhomogeneous F-function plot的示例。显然，在距离范围内，估计的F函数不会达到1，而泊松过程只是趋于平坦。 F函数也应该增加，因此下垂是奇数。当在r函数中手动指定更长的Finhom()范围时，该函数的求值范围仍然超出建议的2000。

很遗憾，我无法共享我的数据。但是，我设法通过一个非常简单的单位正方形上的点图案示例重现了一些错误：

library(spatstat) # version 1.57-1
# define point pattern
ex <- as.ppp(data.frame(x = c(.9, .25, .29, .7, .72, .8, .72, .85), 
                        y = c(.1, .25, .29, .5, .5, .1, .45, .08)), 
                        W = owin(c(0,1), c(0,1)))

plot(ex) 
# testing inhomogeneity
quadrat.test(ex, 3, 3, method = "M", nsim = 500) # p around 0.05
# set bandwidth
diggle <- bw.diggle(ex)
# suggested bandwidth of 0.028

# estimate inhomogeneous F-function
Fi <- Finhom(ex, sigma = diggle)
plot(Fi, main ="Finhom for ex pattern")

该地块已附加here。与我的实际数据类似，该图在r = 0.5（平线）处停止评估，并没有一直上升到1。 有趣的是，当通过lambda函数中的Finhom()参数直接提供强度时，行为会发生变化：

lambda_ex <- density(ex, sigma = diggle, at = "points")
Fi_lambda <- Finhom(ex, lambda = lambda_ex)
plot(Fi_lambda, main ="Finhom w/ lambda directly")

此处，函数的行为为as expected。

我的问题是：

1. 为什么直接提供的强度与Finhom()函数内部估计的强度之间存在差异？

2. 在这里F函数奇怪行为的原因可能是什么？代码问题或用户错误？ （旁注，G函数和K函数也返回奇怪的行为，为了使这个问题简短，我将重点放在F函数上）

谢谢！

Answer 1

正如阿德里安·巴德利（Adrian Baddeley）在其他答案中指出的那样，这本身并不是protected-mode no中的错误。您会期望的

Finhom

应等效于

Fi <- Finhom(ex, sigma = diggle)

但是，这些命令暗示参数lambda_ex <- density(ex, sigma = diggle, at = "points") Fi_lambda <- Finhom(ex, lambda = lambda_ex) 的不同值。在第一种情况下，在窗口中的任何地方都估计了λ，并使用了最小值。在第二种情况下，仅使用给定的lambda值来找到最小值。那当然可以大不相同。 lmin的重要性在下面的代码中进行了说明（请注意，在所有情况下，数据与不均匀泊松之间的差异都是同一类型）。

关于估计在r = 0.5处停止的其他部分不足为奇，因为使用了边界校正并且窗口是单位平方。当r = 0.5时，整个窗口被“刮掉”，因此没有剩余数据。

lmin

^{由reprex package（v0.2.1）于2018-11-24创建}

Answer 2

“不均匀”功能Kinhom，Ginhom，Finhom涉及对点过程的空间变化强度进行调整。它们仅在以下情况下起作用：（a）已正确估算强度，并且（b）积分过程满足某些技术假设，这些假设可以证明调整计算的正确性（请参阅帮助文件中的参考，或spatstat书的相关部分）。

density(ex, sigma=bw.diggle)的图显示出估计强度中的非常高的峰和非常低的波谷，这表明数据不够平滑，因此（a）不令人满意。用bw.scott或bw.CvL获得的结果表现得更好。 （请记住，bw.diggle是为聚集模式设计的。）例如，我得到了一个相当不错的图，

plot(Finhom(ex, sigma=bw.CvL))

是的，当以像素图像和数字矢量形式给出“ lambda”时，结果确实有所不同似乎有些令人不安。正如Ege所解释的，这是因为计算重要自变量lmin的默认值的规则不同。这并不是真正的错误-Ginhom和Finhom的原始代码设计者是这样设计的；我将咨询他们有关是否应该更改它的建议。同时，如果您指定lmin的值，则可以使两个计算一致。