EVOLUTION-MANAGER
Edit File: mgcv-FAQ.html
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"><html xmlns="http://www.w3.org/1999/xhtml"><head><title>R: Frequently Asked Questions for package mgcv</title> <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> <link rel="stylesheet" type="text/css" href="R.css" /> </head><body> <table width="100%" summary="page for mgcv.FAQ {mgcv}"><tr><td>mgcv.FAQ {mgcv}</td><td style="text-align: right;">R Documentation</td></tr></table> <h2>Frequently Asked Questions for package mgcv</h2> <h3>Description</h3> <p> This page provides answers to some of the questions that get asked most often about mgcv</p> <h3>FAQ list</h3> <ol> <li> <p><b>How can I compare gamm models?</b> In the identity link normal errors case, then AIC and hypotheis testing based methods are fine. Otherwise it is best to work out a strategy based on the <code><a href="summary.gam.html">summary.gam</a></code> Alternatively, simple random effects can be fitted with <code><a href="gam.html">gam</a></code>, which makes comparison straightforward. Package <code>gamm4</code> is an alternative, which allows AIC type model selection for generalized models. </p> </li> <li> <p><b>How do I get the equation of an estimated smooth?</b> This slightly misses the point of semi-parametric modelling: the idea is that we estimate the form of the function from data without assuming that it has a particular simple functional form. Of course for practical computation the functions do have underlying mathematical representations, but they are not very helpful, when written down. If you do need the functional forms then see chapter 5 of Wood (2017). However for most purposes it is better to use <code><a href="predict.gam.html">predict.gam</a></code> to evaluate the function for whatever argument values you need. If derivatives are required then the simplest approach is to use finite differencing (which also allows SEs etc to be calculated). </p> </li> <li> <p><b>Some of my smooths are estimated to be straight lines and their confidence intervals vanish at some point in the middle. What is wrong?</b> Nothing. Smooths are subject to sum-to-zero identifiability constraints. If a smooth is estimated to be a straight line then it consequently has one degree of freedom, and there is no choice about where it passes through zero — so the CI must vanish at that point. </p> </li> <li> <p><b>How do I test whether a smooth is significantly different from a straight line</b>. See <code><a href="smooth.construct.tp.smooth.spec.html">tprs</a></code> and the example therein. </p> </li> <li> <p><b>An example from an mgcv helpfile gives an error - is this a bug?</b> It might be, but first please check that the version of mgcv you have loaded into R corresponds to the version from which the helpfile came. Many such problems are caused by trying to run code only supported in a later mgcv version in an earlier version. Another possibility is that you have an object loaded whose name clashes with an mgcv function (for example you are trying to use the mgcv <code>multinom</code> function, but have another object called <code>multinom</code> loaded.) </p> </li> <li> <p><b>Some code from Wood (2006) causes an error: why?</b> The book was written using mgcv version 1.3. To allow for REML estimation of smoothing parameters in versions 1.5, some changes had to be made to the syntax. In particular the function <code>gam.method</code> no longer exists. The smoothness selection method (GCV, REML etc) is now controlled by the <code>method</code> argument to <code>gam</code> while the optimizer is selected using the <code>optimizer</code> argument. See <code><a href="gam.html">gam</a></code> and <a href="http://www.maths.bris.ac.uk/~sw15190/igam/index.html">http://www.maths.bris.ac.uk/~sw15190/igam/index.html</a> for details. </p> </li> <li> <p><b>Why is a model object saved under a previous mgcv version not usable with the current mgcv version?</b> I'm sorry about this issue, I know it's really annoying. Here's my defence. Each mgcv version is run through an extensive test suite before release, to ensure that it gives the same results as before, unless there are good statistical reasons why not (e.g. improvements to p-value approximation, fixing of an error). However it is sometimes necessary to modify the internal structure of model objects in a way that makes an old style object unusable with a newer version. For example, bug fixes or new R features sometimes require changes in the way that things are computed which in turn require modification of the object structure. Similarly improvements, such as the ability to compute smoothing parameters by RE/ML require object level changes. The only fix to this problem is to access the old object using the original mgcv version (available on CRAN), or to recompute the fit using the current mgcv version. </p> </li> <li> <p><b>When using <code>gamm</code> or <code>gamm4</code>, the reported AIC is different for the <code>gam</code> object and the <code>lme</code> or <code>lmer</code> object. Why is this?</b> There are several reasons for this. The most important is that the models being used are actually different in the two representations. When treating the GAM as a mixed model, you are implicitly assuming that if you gathered a replicate dataset, the smooths in your model would look completely different to the smooths from the original model, except for having the same degree of smoothness. Technically you would expect the smooths to be drawn afresh from their distribution under the random effects model. When viewing the gam from the usual penalized regression perspective, you would expect smooths to look broadly similar under replication of the data. i.e. you are really using Bayesian model for the smooths, rather than a random effects model (it's just that the frequentist random effects and Bayesian computations happen to coincide for computing the estimates). As a result of the different assumptions about the data generating process, AIC model comparisons can give rather different answers depending on the model adopted. Which you use should depend on which model you really think is appropriate. In addition the computations of the AICs are different. The mixed model AIC uses the marginal liklihood and the corresponding number of model parameters. The gam model uses the penalized likelihood and the effective degrees of freedom. </p> </li> <li> <p><b>What does 'mgcv' stand for?</b> '<b>M</b>ixed <b>G</b>AM <b>C</b>omputation <b>V</b>ehicle', is my current best effort (let me know if you can do better). Originally it stood for ‘Multiple GCV’, which has long since ceased to be usefully descriptive, (and I can't really change 'mgcv' now without causing disruption). On a bad inbox day '<b>M</b>ad <b>G</b>AM <b>C</b>omputing <b>V</b>ulture'. </p> </li> <li> <p><b>My new method is failing to beat mgcv, what can I do?</b> If speed is the problem, then make sure that you use the slowest basis possible (<code>"tp"</code>) with a large sample size, and experiment with different optimizers to find one that is slow for your problem. For prediction error/MSE, then leaving the smoothing basis dimensions at their arbitrary defaults, when these are inappropriate for the problem setting, is a good way of reducing performance. Similarly, using p-splines in place of derivative penalty based splines will often shave a little more from the performance here. Unlike REML/ML, prediction error based smoothness selection criteria such as Mallows Cp and GCV often produce a small proportion of severe overfits, so careful choise of smoothness selection method can help further. In particular GCV etc. usually result in worse confidence interval and p-value performance than ML or REML. If all this fails, try using a really odd simulation setup for which mgcv is clearly not suited: for example poor performance is almost guaranteed for small noisy datasets with large numbers of predictors. </p> </li></ol> <h3>Author(s)</h3> <p> Simon N. Wood <a href="mailto:simon.wood@r-project.org">simon.wood@r-project.org</a></p> <h3>References</h3> <p>Wood S.N. (2006) Generalized Additive Models: An Introduction with R. Chapman and Hall/CRC Press. </p> <p>Wood S.N. (2017) Generalized Additive Models: An Introduction with R (2nd edition). Chapman and Hall/CRC Press. </p> <hr /><div style="text-align: center;">[Package <em>mgcv</em> version 1.8-28 <a href="00Index.html">Index</a>]</div> </body></html>