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

What to name a definition variable in RAM model? #107

Closed
tbates opened this issue Oct 22, 2019 · 8 comments
Closed

What to name a definition variable in RAM model? #107

tbates opened this issue Oct 22, 2019 · 8 comments
Labels
Models New model types for umx

Comments

@tbates
Copy link
Owner

tbates commented Oct 22, 2019

In RAM, a definition variable "var" is implemented as a latent with mean and variance fixed at zero, and labels= "data.var".

This leaves open to the user what to name the latent.

It's legal in RAM to name the latent "var", but that makes it impossible to also use var as a manifest.

I thinking to make it that in umx, definition variables by default get named "def_var" (i.e., prefix with "def_")

So umxPath(defn = "org1") would create:

mxPath(from = "def_org1", values=0, arrows= 2, free=FALSE)
mxPath(from = "one", to = "def_org1", values=0, free=FALSE, label='data.org1')

But the user can override this with any legal name other than the name of the variable to avoid clashing with manifest space)

In this case the user would specify both the label and the name for the latent.

umxPath(defn = "my_org1_defvar", labels = "org1") would create:

mxPath(from = "my_org1_defvar", values=0, arrows= 2, free=FALSE)
mxPath(from = "one", to = "my_org1_defvar", values=0, free=FALSE, label='data.org1')

thoughts?

@tbates tbates added the Models New model types for umx label Oct 22, 2019
@mcneale
Copy link
Collaborator

mcneale commented Oct 22, 2019

I think conceptualizing definition variables as latent and perhaps exogenous is consistent with their role used as covariates. It is an (perhaps the only) appropriate way to model covariates for ordinal data; with continuous measures it can be simpler to merely regress them out before model fitting. However, definition variables are really placed on paths (not variables) in every case, so if we want to, e.g., moderate a relationship between two latent variables, it can be very useful.

I worry that the automagical approach considers them in too a narrow context as being like covariates, when they are treated quite differently from an observed variable in SEM, including that they require listwise deletion should their values be missing.

@tbates
Copy link
Owner Author

tbates commented Oct 22, 2019

This is just for RAM, where (correct me if wrong) they have to be brought in via a dummy latent variable... there's no current alternative, is there?

In #126 in OpenMx I suggested we add definition variable to the RAM spec, but after a lot of discussion, it wasn't supported, I think? But perhaps this revives that notion, or goes in a new direction?

@mcneale
Copy link
Collaborator

mcneale commented Oct 22, 2019

Definition variables can be part of RAM spec, but exclusively via path labeling - consistent with the way it works in matrix form. So I think in the end there wasn't anything extra needed.

Now, arrows=0 is something that IMO would be useful to add, I need to draft a proposal for that.

@mcneale
Copy link
Collaborator

mcneale commented Oct 22, 2019

I think it should work via path labeling. But perhaps we need a
Definition Age
to go with
Latents x y z
Observed p q r

@tbates
Copy link
Owner Author

tbates commented Oct 22, 2019

Adding definitionVars in addition to latentVars and manifestVars) was the thought, but over to OpenMx. Take some thinking to allow variable to both drive a defVar, and appear in manifests when so required.

I'll notify users about rows dropped due to listwise deletion (already do this for GxE and it's very useful). Will allow arbitrary name for def vars, defaulting to def_varName

cheerios, t

@mcneale
Copy link
Collaborator

mcneale commented Oct 22, 2019

Makes sense. I think the straightforward way to have a definition variable operate as observed and as definition is to just duplicate it in the dataset
mydataframe$ageDummy <- mydataframe$age
which is crude and wasteful of memory, but ought to work fine.

@tbates tbates closed this as completed in bd97b27 Oct 23, 2019
@mcneale
Copy link
Collaborator

mcneale commented Oct 25, 2019

According to the team, definition variables work as long as i) they are in the dataset supplied (don't have to be in Manifest list) and specified as definition variables as, e.g., data.age. Plus, they can be re-used as manifest variables if so listed. So I think this is fully functional. Minus the dropping of rows.

@tbates
Copy link
Owner Author

tbates commented Oct 25, 2019

Agreed... this whole github issue was merely about how umxPath should implement generating a definition variable and whether to autoname them. So we're all on the same page, I believe, and umxPath(defn=) is working well now, including with variables used as a manifest and also as a data.var

I started a blog post on this... not finished yet.

http://tbates.github.io/advanced/1995/03/10/detailed-Definition-variables-in-RAM.html

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Models New model types for umx
Projects
None yet
Development

No branches or pull requests

2 participants