Bookmark and Share

Notice: On April 23, 2014, Statalist moved from an email list to a forum, based at statalist.org.


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: st: GAMFIT failure despite updated gam


From   Nick Cox <[email protected]>
To   [email protected]
Subject   Re: st: GAMFIT failure despite updated gam
Date   Fri, 30 Sep 2011 01:13:38 +0100

This is even less of an answer to Matthew's question, but I'll offer a
few very personal rules of thumb from practical experience in terms of
various smoothers. Others may want to disagree or add others, which
would be interesting to me at least.

They arise particularly from the simplest interesting case, in which y
varies in a possibly nonlinear way with one x and there isn't an
obvious equation from the literature to try. (If there's physics or
biology or economics or whatever that suggests an equation, it's
clearly one to try.)  Here I act as a scientist working with
environmental data in my field thinking of what will convince others
as being fair to the data and physically sensible. (I'm a geographer,
not a statistician, after all.)

0. Never believe one smooth unless a different smooth using a
different approach agrees very well with it.

1. In practice, the default choices for restricted cubic splines and
fractional polynomials usually work very well and often agree very
closely.

2. If the agreement in #1 is of a linear relationship, back off and go
for linear regression any way.

3. If the agreement in #1 suggests a simple transformation or link
function, back off and go for that instead.

4. The default choices for -lowess- and -lpoly- are often
undersmoothed. In the case of -lpoly-, there is a clear denial in the
documentation that the defaults are anything but arbitrary, but
playing with the option choices is still unattractive. -lowess- can be
very slow with large datasets. -lowess- was for a long time my
favourite smoothing method, but I've almost stopped using it. In
principle, I like the idea of local polynomials; it's just that the
practice is usually disappointing.


On Fri, Sep 30, 2011 at 12:17 AM, Nick Cox <[email protected]> wrote:
> I don't know what the difficulty is here. I'd just offer the oblique
> comment that work with this model seems to have faded away. In Stata,
> at least, it's much easier to work with restricted cubic splines or
> fractional polynomials.
>
> Nick
>
> On Thu, Sep 29, 2011 at 10:18 PM, Matthew Baldwin, MD
> <[email protected]> wrote:
>
>>   Despite having downloaded the most uptodate gam program that includes gam,
>> gamfit, gambig, gamhuge, gamhug2, unzipping it, and indicating to Stata
>> where the program is, I still get the following error message below.
>>
>>   Of note, I run Windows 7, and initally received an r(603) message after
>> running the code below, and after doing what was recommended: 'update all,
>> update swap', and now running Stata 11 as an administrator, I still cant get
>> the gam program to work.
>>
>> It worked previously on this computer with this code before it was
>> rebuilt/reinstalled.  Any help is greatly appreciated.
>>
>> ssc desc gam
>> ssc install gam
>> !unzip gam.zip
>>
>> global GAMDIR C:\ado\plus\g\
>> gam yvar xvar if dcyear > 2005, f(binomial) link(logit) df(xvar:3) big
>> GAMFIT failure, $.out not found
>> stats not found
>> r(111);
>>
>

*
*   For searches and help try:
*   http://www.stata.com/help.cgi?search
*   http://www.stata.com/support/statalist/faq
*   http://www.ats.ucla.edu/stat/stata/


© Copyright 1996–2018 StataCorp LLC   |   Terms of use   |   Privacy   |   Contact us   |   Site index