search

stan-dev / rstanarm

rstanarm R package for Bayesian applied regression modeling
https://mc-stan.org/rstanarm
GNU General Public License v3.0
389 stars 134 forks source link

possibly emulate the gamm4 package / function #32

Closed bgoodri closed 8 years ago

bgoodri commented 9 years ago

The gamm4 R package inputs syntax for estimating generalized additive models, converts it internally to lme4 syntax, and uses lmer to estimate the parameters. It sounds as if (from the appendix of the lme4 vignette and the documentation of gamm4) that we could just copy some of this R code and make a stan_gamm4() function with no additional Stan code and it is quite likely that the decov prior will make the estimates of the smoothing parameters more reliable.

andrewgelman commented 9 years ago

kool

On Nov 6, 2015, at 11:34 PM, bgoodri notifications@github.com wrote:

The gamm4 R package inputs syntax for estimating generalized additive models, converts it internally to lme4 syntax, and uses lmer to estimate the parameters. It sounds as if (from the appendix of the lme4 vignette and the documentation of gamm4) that we could just copy some of this R code and make a stan_gamm4() function with no additional Stan code and it is quite likely that the decov prior will make the estimates of the smoothing parameters more reliable.

— Reply to this email directly or view it on GitHub https://github.com/stan-dev/rstanarm/issues/32.

jgabry commented 9 years ago

We should definitely do this. Although the name stan_gamm4 is kind of ugly (the gamm4 part). I'd rather use stan_gamm even if it's the gamm4 function it's emulating, which we can mention in the doc.

On Friday, November 6, 2015, bgoodri notifications@github.com wrote:

The gamm4 R package inputs syntax for estimating generalized additive models, converts it internally to lme4 syntax, and uses lmer to estimate the parameters. It sounds as if (from the appendix of the lme4 vignette and the documentation of gamm4) that we could just copy some of this R code and make a stan_gamm4() function with no additional Stan code and it is quite likely that the decov prior will make the estimates of the smoothing parameters more reliable.

— Reply to this email directly or view it on GitHub https://github.com/stan-dev/rstanarm/issues/32.

bgoodri commented 9 years ago

I agree that the 4 is ugly but to me, it is not ugly enough to break our convention that stan_foo emulates foo. There is already a gamm function in the mcgv package that is conceptually similar but has different arguments.

On Sat, Nov 7, 2015 at 12:38 AM, Jonah Gabry notifications@github.com wrote:

We should definitely do this. Although the name stan_gamm4 is kind of ugly (the gamm4 part). I'd rather use stan_gamm even if it's the gamm4 function it's emulating, which we can mention in the doc.

On Friday, November 6, 2015, bgoodri notifications@github.com wrote:

The gamm4 R package inputs syntax for estimating generalized additive models, converts it internally to lme4 syntax, and uses lmer to estimate the parameters. It sounds as if (from the appendix of the lme4 vignette and the documentation of gamm4) that we could just copy some of this R code and make a stan_gamm4() function with no additional Stan code and it is quite likely that the decov prior will make the estimates of the smoothing parameters more reliable.

— Reply to this email directly or view it on GitHub https://github.com/stan-dev/rstanarm/issues/32.

— Reply to this email directly or view it on GitHub https://github.com/stan-dev/rstanarm/issues/32#issuecomment-154628462.

jgabry commented 9 years ago

I don't feel too strongly about it. So I'm fine with gamm4 if you prefer it. At some point we're inevitably just drawing arbitrary limits. Using the gamm name instead of gamm4 is a much more minor difference (in terms of emulation) than the difference between lm and what stan_lm does.

On Saturday, November 7, 2015, bgoodri notifications@github.com wrote:

I agree that the 4 is ugly but to me, it is not ugly enough to break our convention that stan_foo emulates foo. There is already a gamm function in the mcgv package that is conceptually similar but has different arguments.

On Sat, Nov 7, 2015 at 12:38 AM, Jonah Gabry <notifications@github.com javascript:_e(%7B%7D,'cvml','notifications@github.com');> wrote:

We should definitely do this. Although the name stan_gamm4 is kind of ugly (the gamm4 part). I'd rather use stan_gamm even if it's the gamm4 function it's emulating, which we can mention in the doc.

On Friday, November 6, 2015, bgoodri <notifications@github.com javascript:_e(%7B%7D,'cvml','notifications@github.com');> wrote:

The gamm4 R package inputs syntax for estimating generalized additive models, converts it internally to lme4 syntax, and uses lmer to estimate the parameters. It sounds as if (from the appendix of the lme4 vignette and the documentation of gamm4) that we could just copy some of this R code and make a stan_gamm4() function with no additional Stan code and it is quite likely that the decov prior will make the estimates of the smoothing parameters more reliable.

— Reply to this email directly or view it on GitHub https://github.com/stan-dev/rstanarm/issues/32.

— Reply to this email directly or view it on GitHub https://github.com/stan-dev/rstanarm/issues/32#issuecomment-154628462.

— Reply to this email directly or view it on GitHub https://github.com/stan-dev/rstanarm/issues/32#issuecomment-154628833.

bgoodri commented 9 years ago

Yeah, I tend to think of the relationship between stan_foo and foo is that stan_foo emulates foo's syntax and implements foo's likelihood. With the priors that stan_foo offers, it may be the case that the results are appreciably different from those of foo. Maybe this deserves more emphasis in the documentation somewhere if people are prone to mistakenly think that stan_foo is supposed to emulate foo's results but maybe gets the uncertainty better and comes with more cool graphs.

On Sat, Nov 7, 2015 at 1:33 AM, Jonah Gabry notifications@github.com wrote:

I don't feel too strongly about it. So I'm fine with gamm4 if you prefer it. At some point we're inevitably just drawing arbitrary limits. Using the gamm name instead of gamm4 is a much more minor difference (in terms of emulation) than the difference between lm and what stan_lm does.

On Saturday, November 7, 2015, bgoodri notifications@github.com wrote:

I agree that the 4 is ugly but to me, it is not ugly enough to break our convention that stan_foo emulates foo. There is already a gamm function in the mcgv package that is conceptually similar but has different arguments.

On Sat, Nov 7, 2015 at 12:38 AM, Jonah Gabry <notifications@github.com javascript:_e(%7B%7D,'cvml','notifications@github.com');> wrote:

We should definitely do this. Although the name stan_gamm4 is kind of ugly (the gamm4 part). I'd rather use stan_gamm even if it's the gamm4 function it's emulating, which we can mention in the doc.

On Friday, November 6, 2015, bgoodri <notifications@github.com javascript:_e(%7B%7D,'cvml','notifications@github.com');> wrote:

The gamm4 R package inputs syntax for estimating generalized additive models, converts it internally to lme4 syntax, and uses lmer to estimate the parameters. It sounds as if (from the appendix of the lme4 vignette and the documentation of gamm4) that we could just copy some of this R code and make a stan_gamm4() function with no additional Stan code and it is quite likely that the decov prior will make the estimates of the smoothing parameters more reliable.

— Reply to this email directly or view it on GitHub https://github.com/stan-dev/rstanarm/issues/32.

— Reply to this email directly or view it on GitHub <https://github.com/stan-dev/rstanarm/issues/32#issuecomment-154628462 .

— Reply to this email directly or view it on GitHub https://github.com/stan-dev/rstanarm/issues/32#issuecomment-154628833.

— Reply to this email directly or view it on GitHub https://github.com/stan-dev/rstanarm/issues/32#issuecomment-154637364.

andrewgelman commented 9 years ago

I don’t think it will be hard to convey to people that stan_foo is foo PLUS, in that we have the option of full Bayes as well as the option of informative priors. Users of stan_foo will want foo PLUS. If they only wanted foo, they’d stick with foo. They’re switching to Stan to get more stable estimates or better uncertainty estimates, not to cool graphs.

On Nov 7, 2015, at 1:40 AM, bgoodri notifications@github.com wrote:

Yeah, I tend to think of the relationship between stan_foo and foo is that stan_foo emulates foo's syntax and implements foo's likelihood. With the priors that stan_foo offers, it may be the case that the results are appreciably different from those of foo. Maybe this deserves more emphasis in the documentation somewhere if people are prone to mistakenly think that stan_foo is supposed to emulate foo's results but maybe gets the uncertainty better and comes with more cool graphs.

On Sat, Nov 7, 2015 at 1:33 AM, Jonah Gabry notifications@github.com wrote:

I don't feel too strongly about it. So I'm fine with gamm4 if you prefer it. At some point we're inevitably just drawing arbitrary limits. Using the gamm name instead of gamm4 is a much more minor difference (in terms of emulation) than the difference between lm and what stan_lm does.

On Saturday, November 7, 2015, bgoodri notifications@github.com wrote:

I agree that the 4 is ugly but to me, it is not ugly enough to break our convention that stan_foo emulates foo. There is already a gamm function in the mcgv package that is conceptually similar but has different arguments.

On Sat, Nov 7, 2015 at 12:38 AM, Jonah Gabry <notifications@github.com javascript:_e(%7B%7D,'cvml','notifications@github.com');> wrote:

We should definitely do this. Although the name stan_gamm4 is kind of ugly (the gamm4 part). I'd rather use stan_gamm even if it's the gamm4 function it's emulating, which we can mention in the doc.

On Friday, November 6, 2015, bgoodri <notifications@github.com javascript:_e(%7B%7D,'cvml','notifications@github.com');> wrote:

The gamm4 R package inputs syntax for estimating generalized additive models, converts it internally to lme4 syntax, and uses lmer to estimate the parameters. It sounds as if (from the appendix of the lme4 vignette and the documentation of gamm4) that we could just copy some of this R code and make a stan_gamm4() function with no additional Stan code and it is quite likely that the decov prior will make the estimates of the smoothing parameters more reliable.

— Reply to this email directly or view it on GitHub https://github.com/stan-dev/rstanarm/issues/32.

— Reply to this email directly or view it on GitHub <https://github.com/stan-dev/rstanarm/issues/32#issuecomment-154628462 .

— Reply to this email directly or view it on GitHub https://github.com/stan-dev/rstanarm/issues/32#issuecomment-154628833.

— Reply to this email directly or view it on GitHub https://github.com/stan-dev/rstanarm/issues/32#issuecomment-154637364.

— Reply to this email directly or view it on GitHub https://github.com/stan-dev/rstanarm/issues/32#issuecomment-154638629.

jgabry commented 8 years ago

@bgoodri Do the guts of the gam object still need to be filled in with the rstanarm estimates? If so, if you can do that then I can set up a plotting method for the stan_gamm4 models that makes use of the gam plots.

bgoodri commented 8 years ago

Ideally yes. Also, I'm not sure what would happen with posterior_predict() if newdata has different values of the smoothing terms. I'll try to look at it today.

On Wed, Jan 6, 2016 at 11:59 AM, Jonah Gabry notifications@github.com wrote:

@bgoodri https://github.com/bgoodri Do the guts of the gam object still need to be filled in with the rstanarm estimates? If so, if you can do that then I can set up a plotting method for the stan_gamm4 models that makes use of the gam plots.

— Reply to this email directly or view it on GitHub https://github.com/stan-dev/rstanarm/issues/32#issuecomment-169387955.

bgoodri commented 8 years ago

This is minimally implemented so closing but see #46