gam
, except that the numerical methods
are designed for datasets containing upwards of several tens of thousands of data (see Wood, Goude and Shaw, 2014). The advantage
of bam
is much lower memory footprint than gam
, but it can also be much faster,
for large datasets. bam
can also compute on a cluster set up by the parallel package.bam(formula,family=gaussian(),data=list(),weights=NULL,subset=NULL,
na.action=na.omit, offset=NULL,method="fREML",control=list(),
scale=0,gamma=1,knots=NULL,sp=NULL,min.sp=NULL,paraPen=NULL,
chunk.size=10000,rho=0,AR.start=NULL,sparse=FALSE,cluster=NULL,
nthreads=NA,gc.level=1,use.chol=FALSE,samfrac=1,
drop.unused.levels=TRUE,...)
formula.gam
and also gam.models
).
This is exactly like the formula for a GLM except that smooth terms, s
and te
environment(formula)
: typically the environment from
which gam
is called.formula
: this conforms to the behaviour of
lm
and glm
."GCV.Cp"
to use GCV for unknown scale parameter and
Mallows' Cp/UBRE/AIC for known scale. "GACV.Cp"
is equivalent, but using GACV in place of GCV. "REML"
for REML estimatiogam.control
. Any control parameters not supplied stay at their default values.k
value
supplied (note that the number of knots is nfull.sp
, in the
returned object, will need to be added to what is supplied here to get the
smoothing parameters actuagam.models
explains more.4*p
if chunk.size < 4*p
where p
is the number of coefficients.TRUE
at first observation of an independent
section of AR1 correlation. Very first observation in data frame does not need this. If NULL
then
there are no breaks in AR1 correlaion.te(...,bs="ps",np=FALSE)
then in principle computation could be made faster using sparse matrix methods, and you could set this to TRUE
.
In practice the speedbam
can compute the computationally dominant QR decomposition in parallel using parLapply
from the parallel
package, if it is supplied with a cluster on which to do this (a cluster heNA
set to max(1,length(cluster))
.bam
uses a very stable QR update approach to obtaining the QR decomposition
of the model matrix. For well conditioned models an alternative accumulates the crossproduct of the model matrix
and then finds its Choleski decomposition,gam.fit
(such as mustart
)."gam"
as described in gamObject
."tp"
basis is used. You must have more unique combinations of covariates than the model has total parameters. (Total parameters is sum of basis dimensions plus sum of non-spline terms less the number of spline terms).
This routine is less stable than `gam' for the same dataset.
The negbin family is only supported for the *known theta* case.
AIC computation does not currently take account of an AR1 model, if used.
bam
operates by first setting up the basis characteristics for the smooths, using a representative subsample
of the data. Then the model matrix is constructed in blocks using predict.gam
. For each block the factor R,
from the QR decomposition of the whole model matrix is updated, along with Q'y. and the sum of squares of y. At the end of
block processing, fitting takes place, without the need to ever form the whole model matrix. In the generalized case, the same trick is used with the weighted model matrix and weighted pseudodata, at each step of the PIRLS. Smoothness selection is performed on the working model at each stage (performance oriented iteration), to maintain the small memory footprint. This is trivial to justify in the case of GCV or Cp/UBRE/AIC based model selection, and for REML/ML is justified via the asymptotic multivariate normality of Q'z where z is the IRLS pseudodata.
For full method details see Wood, Goude and Shaw (2014).
Note that POI is not as stable as the default nested iteration used with gam
, but that for very large, information rich,
datasets, this is unlikely to matter much.
Note also that it is possible to spend most of the computational time on basis evaluation, if an expensive basis is used. In practice this means that the default "tp"
basis should be avoided: almost any other basis (e.g. "cr"
or "ps"
)
can be used in the 1D case, and tensor product smooths (te
) are typically much less costly in the multi-dimensional case.
If cluster
is provided as a cluster set up using makeCluster
(or makeForkCluster
) from the parallel
package, then the rate limiting QR decomposition of the model matrix is performed in parallel using this cluster. Note that the speed ups are often not that great. On a multi-core machine it is usually best to set the cluster size to the number of physical cores, which is often less than what is reported by detectCores
. Using more than the number of physical cores can result in no speed up at all (or even a slow down). Note that a highly parallel BLAS may negate all advantage from using a cluster of cores. Computing in parallel of course requires more memory than computing in series. See examples.
If the argument sparse=TRUE
then QR updating is replaced by an alternative scheme, in which the model matrix is stored whole
as a sparse matrix. This only makes sense if all smooths are P-splines and all tensor products are of the
form te(...,bs="ps",np=FALSE)
, but no check is made. The computations are then based on the Choleski decomposition of
the crossproduct of the sparse model matrix. Although this crossproduct is nearly dense, sparsity should make its
formation efficient, which is useful as it is the leading order term in the operations count. However there is no benefit
in using sparse methods to form the Choleski decomposition, given that the crossproduct is dense.
In practice the sparse matrix handling overheads mean that modest or no speed ups are produced
by this approach, while the computation is less stable than the default, and the memory footprint often higher
(but please let the author know if you find an example where the speedup is really worthwhile).
mgcv.parallel
,
mgcv-package
, gamObject
, gam.models
, smooth.terms
,
linear.functional.terms
, s
,
te
predict.gam
,
plot.gam
, summary.gam
, gam.side
,
gam.selection
, gam.control
gam.check
, linear.functional.terms
negbin
, magic
,vis.gam
library(mgcv)
## See help("mgcv-parallel") for using bam in parallel
## Some examples are marked 'Not run' purely to keep
## checking load on CRAN down. Sample sizes are small for
## the same reason.
set.seed(3)
dat <- gamSim(1,n=25000,dist="normal",scale=20)
bs <- "cr";k <- 12
b <- bam(y ~ s(x0,bs=bs)+s(x1,bs=bs)+s(x2,bs=bs,k=k)+
s(x3,bs=bs),data=dat)
summary(b)
plot(b,pages=1,rug=FALSE) ## plot smooths, but not rug
plot(b,pages=1,rug=FALSE,seWithMean=TRUE) ## `with intercept' CIs
ba <- bam(y ~ s(x0,bs=bs,k=k)+s(x1,bs=bs,k=k)+s(x2,bs=bs,k=k)+
s(x3,bs=bs,k=k),data=dat,method="GCV.Cp") ## use GCV
summary(ba)
## A Poisson example...
k <- 15
dat <- gamSim(1,n=21000,dist="poisson",scale=.1)
system.time(b1 <- bam(y ~ s(x0,bs=bs)+s(x1,bs=bs)+s(x2,bs=bs,k=k),
data=dat,family=poisson()))
b1
## Sparse smoother example...
dat <- gamSim(1,n=10000,dist="poisson",scale=.1)
system.time( b3 <- bam(y ~ te(x0,x1,bs="ps",k=10,np=FALSE)+
s(x2,bs="ps",k=30)+s(x3,bs="ps",k=30),data=dat,
method="REML",family=poisson(),sparse=TRUE))
b3
Run the code above in your browser using DataLab