Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feature/lm list #108

Open
wants to merge 12 commits into
base: master
Choose a base branch
from
Open

Feature/lm list #108

wants to merge 12 commits into from

Conversation

bgoodri
Copy link
Contributor

@bgoodri bgoodri commented Jul 16, 2016

@jgabry Is there anything else to implement for this partially pooled linear model before merging? It is failing on travis for mysterious reasons but passing locally.

Is the stuff you were doing to do pp_check by group on a branch somewhere? We could use something like that for this. example("lmList", package = "lme4") has a nice (lattice-based) plot.

this is based on lme4::lmList but is restricted to linear models and does partial pooling rather than no pooling
@bgoodri
Copy link
Contributor Author

bgoodri commented Jul 17, 2016

Upon further review, the problem is that we have a massive memory leak somewhere.

@jgabry
Copy link
Member

jgabry commented Jul 18, 2016

Haven't had a chance to look at this yet. Probably Thursday or Friday at
this point.

On Saturday, July 16, 2016, bgoodri notifications@github.com wrote:

@jgabry https://github.com/jgabry Is there anything else to implement
for this partially pooled linear model before merging? It is failing on
travis for mysterious reasons but passing locally.

Is the stuff you were doing to do pp_check by group on a branch
somewhere? We could use something like that for this. example("lmList",

package = "lme4") has a nice (lattice-based) plot.

You can view, comment on, or merge this pull request online at:

#108
Commit Summary

  • introduce stan_lmList function
  • stan_lmList.R: add details
  • lm.Rmd: clarify effective parameters count
  • SETTINGS-rstan.txt: use only 1 core again

File Changes

Patch Links:


You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#108, or mute the thread
https://github.com/notifications/unsubscribe-auth/AHb4Q-z-NB6NkVyIhQB9H7ysA1iLfHunks5qWTpZgaJpZM4JOFdF
.

@bgoodri
Copy link
Contributor Author

bgoodri commented Jul 19, 2016

OK, it is fundamentally passing on Travis now

@jgabry
Copy link
Member

jgabry commented Jul 21, 2016

@bgoodri Just started going through this. One thing I noticed is that it doesn't seem to work with loo when k_threshold is specified:

Error: grouping factors must have > 1 sampled level
Called from: checkNlevels(reTrms$flist, n = n, control)

which comes from these new lines in .pp_data (which gets called by log_lik when newdata is specified):

  if (inherits(object, "lmList")) {
    f <- as.character(object$formula)
    f <- as.formula(paste(f[2], "~", "-1 + (", f[3], ")"))
    g <- glFormula(f, newdata) # error happens here

@bgoodri
Copy link
Contributor Author

bgoodri commented Jul 21, 2016

Looks like I need to pass a glmerControl() to glFormula() like we do in
stan_glmer()

On Thu, Jul 21, 2016 at 6:16 PM, Jonah Gabry notifications@github.com
wrote:

@bgoodri https://github.com/bgoodri Just started going through this.
One thing I noticed is that it doesn't seem to work with loo when
k_threshold is specified:

Error: grouping factors must have > 1 sampled levelCalled from: checkNlevels(reTrms$flist, n = n, control)

which comes from these new lines in .pp_data (which gets called by log_lik
when newdata is specified):

if (inherits(object, "lmList")) {
f <- as.character(object$formula)
f <- as.formula(paste(f[2], "~", "-1 + (", f[3], ")"))
g <- glFormula(f, newdata) # error happens here


You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#108 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/ADOrqoAd1geuV4HzhHLbcM1zoSospZXMks5qX-_MgaJpZM4JOFdF
.

@jgabry
Copy link
Member

jgabry commented Jul 21, 2016

Also, do you know why this gives such crazy fitted values (~ -500 mpg) for some obs?

> post <- stan_lmList(mpg ~ disp + wt + hp | cyl, data = mtcars, 
                    prior = R2(0.25),cores = 4)

> post$fitted.values
 [1] -445.53464662 -446.08058883   34.64203080 -627.35905689    4.99964496 -559.32449712
 [7]    4.32078553   32.79270824   33.07806188 -481.47190037 -481.47190037    8.84858062
[13]    8.85052841    8.85024197   -0.49029885   -0.03220982    0.74953141   36.04257352
[19]   36.17966384   36.40331209   34.06388449    7.18722826    7.83633447    4.78253823
[25]    3.14412690   36.02574804   34.05075351   35.25456873    4.55598688 -519.11948085
[31]    6.18239069   34.02475271

@bgoodri
Copy link
Contributor Author

bgoodri commented Jul 21, 2016

Those are the 6 cylinder cars but I don't know what it isn't matching up
more closely with colMeans(posterior_predict())

On Thu, Jul 21, 2016 at 6:33 PM, Jonah Gabry notifications@github.com
wrote:

Also, do you know why this gives such crazy fitted values (~ -500 mpg) for
some obs?

post <- stan_lmList(mpg ~ disp + wt + hp | cyl, data = mtcars,
prior = R2(0.25),cores = 4)

post$fitted.values
[1] -445.53464662 -446.08058883 34.64203080 -627.35905689 4.99964496 -559.32449712
[7] 4.32078553 32.79270824 33.07806188 -481.47190037 -481.47190037 8.84858062
[13] 8.85052841 8.85024197 -0.49029885 -0.03220982 0.74953141 36.04257352
[19] 36.17966384 36.40331209 34.06388449 7.18722826 7.83633447 4.78253823
[25] 3.14412690 36.02574804 34.05075351 35.25456873 4.55598688 -519.11948085
[31] 6.18239069 34.02475271


You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#108 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/ADOrqjYsDilCAeLcdhETbd0oTYIJ6KmSks5qX_POgaJpZM4JOFdF
.

@jgabry
Copy link
Member

jgabry commented Jul 21, 2016

Yeah, two issues I think. One is that it's so different from posterior_predict. The other is that the fitted value is negative 500 miles per gallon, which seems impossible since I would think 0 is a logical lower bound on mpg. So maybe negative 5 could make sense for a noisy estimate but negative 500?

@bgoodri
Copy link
Contributor Author

bgoodri commented Jul 21, 2016

I think the ordering in $coefficients is wrong.

On Thu, Jul 21, 2016 at 6:48 PM, Jonah Gabry notifications@github.com
wrote:

Yeah, two issues I think. One is that it's so different from
posterior_predict. The other is that the fitted value is negative 500
miles per gallon, which seems impossible since I would think 0 is a logical
lower bound on mpg. So maybe negative 5 could make sense for a noisy
estimate but negative 500?


You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#108 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/ADOrqqbG4bhv-WVVN0r5qHIGMYjEOWYFks5qX_ctgaJpZM4JOFdF
.

@jgabry jgabry added the feature label Jul 30, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants