-
Notifications
You must be signed in to change notification settings - Fork 5
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
The order of priors in cbc_design and its connection to cbc_profiles #24
Comments
Yes, you are understanding how the reference cases are set in both {logitr} and {cbcTools}:
I like the suggestion of providing explicit names for the priors for clarity. That should be relatively easy to implement, though I would probably use a vector instead of a list since the priors are already defined as a vector, e.g.: priors <- c(Low = -1.8, Medium = 1.9, High = 5.2) Note that I left out the reference level in the priors, which I think should be intuitive enough. In fact, I could modify this such that if you're using a named vector whatever level you leave out will be used as the reference level, e.g.: priors <- c(Unavailable = -1.8, Low = 1.9, Medium = 5.2) In the above case the This shouldn't be too difficult to implement. |
I think that would be a great implementation, and it's reasonable to assume that the left-out category is the reference. Especially considering the fact that the output of logitr automatically doesn't include the reference categories, I think it would be easy to connect those dots. Thank you! |
Background: I have conducted a pilot study, designed using cbcTools with zero priors, and the results of the experiment were analyzed using logitr. When estimating the model in logitr, for one of my categorical variables I wanted to use a different category as reference. logitr (I'm assuming) was picking the first category alphabetically, and using that as reference. I used the
factor()
function, as specified in the paper on logitr (under section 5.4. Continuous and discrete variable coding), and identified another category as reference. Let's call the attributeInformation
, and the levels arec("High", "Medium", "Low", "Unavailable")
. In logitr, if I didn't use the following code,"High"
would be used as the reference category, but I wanted"Unavailable"
to be the reference:Now, the resulting MNL model coefficient estimates are:
My understanding based on the examples provided for cbc_design, is that when creating profiles using cbc_profiles, the order of levels when identifying the categorical attributes determines the order of priors in cbc_design. The first level will be ignored in the priors vector (or considered as reference), and priors for the rest of the levels will be introduced. So now that I will be including my priors, and because I used
"Unavailable"
as reference category in obtaining those priors, I think I need to make sure the order of levels forInformation
are consistent:My Questions:
Are my assumptions correct that 1) logitr alphabetically selects the reference category, 2) the order of levels for a categorical attribute determines the order of the priors, and 3) the prior for the first level needs to be ignored in the vector of priors, if that level was used as reference?
Considering that using priors is the main point of DB-Efficient designs, is there a way to increase the perceived reliability of this process when identifying priors for categorical attributes, maybe by using a named list (aka dictionary) to identify the priors? I think improving this aspect will help users make sure they are identifying the correct priors for each level, without having to rely on identifying the values in a specific order that may be different from their original design. For example:
If creating a nested list like above wreaks havoc on the internal operations, maybe the named list can be assigned to a variable before using cbc_design, and then that variable can be identified as the prior for a categorical attribute? For example:
The text was updated successfully, but these errors were encountered: