我使用bam中的mgcv函数在多个数据集上拟合相同的广义加法模型。虽然对于我的大多数数据集而言，拟合在10到20分钟的合理时间内完成。对于一些数据集，运行需要10个多小时才能完成。我发现慢速情况之间没有任何相似之处，最终的拟合既不是特别好也不是坏，也不包含任何明显的异常值。
我怎样才能弄清楚为什么这些实例的拟合速度如此之慢？我怎么能加快这些速度呢？
我的模型包含两个平滑项（使用循环三次样条基）和一些额外的数值和因子变量。总共估计300个系数（包括平滑项的系数）。我故意将结数保持在信息理论上最佳数字以下，以加快拟合过程。我的数据集包含大约850k行。
这是函数调用：
bam(
value
~ 0
+ weekday_x
+ weekday
+ time
+ "a couple of factor variables encoding special events"
+ delta:weekday
+ s(share_of_year, k=length(knotsYear), bs="cc")
+ s(share_of_year_x, k=length(knotsYear), bs="cc")
, knots=list(
share_of_year=knotsYear
, share_of_year_x=knotsYear
)
, family=quasipoisson()
, data=data
)
knotsYears包含26节。
对于大多数情况，这种模式合理地快速收敛，但对于少数情况来说速度非常慢。
答案 0 :(得分：7)
在如上所述的典型模型中，没有张量平滑te或ti，我的经验是REML迭代在某些情况下失败。
规范bam实施使用fast.REML.fit。这个例程的收敛性测试需要修复，但是当Simon继续前进并且现在更多地关注discrete方法时，他并不热衷于修复它。固定版本（目前）仅在扩展包中提供用于测试的“哲源插件”，作为我的博士论文的补充。但fast.REML.fit也不是那么脆弱，而且这种融合失败的情况并不常见，否则成堆的重大报道会在2012年解决这个问题。
以下内容只是帮助您进行检查而非修复。
让fit成为您需要10个小时的拟合模型，请检查fit$outer.info。这给出了它所需的REML迭代次数，以及渐变和Hessian等收敛信息。如果你看到iter = 200，或任何说“失败”之类的失败的信息，那么你就知道为什么需要这么长时间。但是如果你看一下渐变，很可能你会发现它几乎为零。换句话说，REML迭代实际上已收敛，但fast.REML.fit未能检测到它。
由于您拟合GAM而不是AM（具有高斯响应的加性模型），因此在REML迭代之外还存在另一个P-IRLS（惩罚迭代重新加权最小二乘）。是的，整个（规范）bam估计是一个双循环嵌套，称为“性能迭代”。这也可能失败，但这种失败更为内在，可能无法克服，因为“性能迭代”无法保证收敛。因此，检查fit$iter以查看它是否也非常大（在最坏的情况下它可能是200）。 mgcv手册有一个专门的部分?gam.convergence讨论这种类型的收敛失败，这是“外部迭代”是可取的驱动原因。但是，对于大型数据集，“外部迭代”实现起来太昂贵了。因此，请注意“性能迭代”。
mgcv有一个“跟踪”选项。如果在调用control = gam.control(trace = TRUE)时设置bam，则偏差信息和迭代计数器将在“性能迭代”时显示在屏幕上。这为您提供了明确的惩罚性偏差路径，因此您可以检查它是否在某个地方骑行或被困。这比存储在fit$iter中的单个迭代编号更具信息性。
也许您想尝试新的discrete = TRUE（2015年添加; 2017年正式发布的论文）。它使用新的拟合迭代。我们（很多）比旧方法更快乐地测试它的实际收敛能力。使用时，也可以打开“跟踪”。如果它无法收敛，请考虑报告它，但我们需要一个可重复的案例。