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

non-observed categories in brandom #71

Open
carlganz opened this issue Feb 16, 2017 · 2 comments
Open

non-observed categories in brandom #71

carlganz opened this issue Feb 16, 2017 · 2 comments
Assignees
Labels

Comments

@carlganz
Copy link

Hello,

Apologies for all the issues I've raised recently. My coauthor and I have found a lot of value in mboost so we have been using it a lot lately.

From the docs:

For a categorical covariate with non-observed categories bols(x) and brandom(x) both assign a zero effect to these categories. However, the non-observed categories must be listed in levels(x). Thus, predictions are possible for new observations if they correspond to this category.

This behavior is ideal, however I don't believe it is working, but it is possible I am using levels(x) incorrectly.

library(mboost)

myData <- data.frame(
  ZIP  = factor(c("90046","91423", "90064"),
                # include non-observed categoreies in levels
                levels = c("90046","91423", "90064","95432")),
  uninsured = factor(c(0,1,1))
)


model <- mboost(
  uninsured ~ brandom(ZIP, df = 2), data = myData,
  family = Binomial(), control = 
    boost_control(mstop = 1000, nu = 0.01, trace=TRUE)
)
# warning about dropping unobserved levels


newData <- data.frame(
  ZIP = factor(c("90046","95432"), 
               # use same levels in new data
               levels = c("90046","91423", "90064","95432"))
)

predict(model, newData)
# errors

Thank you for your help and the wonderful package.

Regards

@hofnerb
Copy link
Member

hofnerb commented Feb 17, 2017

You are absolutely right. This is a bug (or at least not in line with the documentation). I'll dig into that.

(Btw there is no need to apologize, we very much welcome bug reports / questions / feature requests. This helps us providing better software)

@hofnerb hofnerb self-assigned this Feb 17, 2017
@hofnerb hofnerb added the bug label Feb 17, 2017
@hofnerb
Copy link
Member

hofnerb commented Feb 17, 2017

Hm, the point is that we just fixed a related bug by disallowing empty categories (see #47). The easy solution would be to simply remove the comment from the docs. However, on the other hand, it would be quite handy to have it back up and working. This might perhaps also solve #49.

The problem: I cannot remember how this worked or was supposed to work in the first place.

@mayrandy mayrandy self-assigned this Oct 29, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants