为什么某些数据来自mgcv的bam会变慢？

Question

我使用bam函数from 在多个数据集上拟合相同的广义加法模型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节.

对于大多数情况,这种模型合理地快速收敛,但对于少数情况来说速度非常慢.

Answer 1

最可能的原因是:"fREML"失败

在如上所述的典型模型中,没有张量平滑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年正式出版的论文).它使用新的拟合迭代.我们(很多)比旧方法更快乐地测试它的实际收敛能力.使用时,也可以打开"跟踪".如果它无法收敛,请考虑报告它,但我们需要一个可重复的案例.