lavaan allows numeric grouping variables?

[cjvanlissa]

Dear Yves,

I got this puzzling Issue on tidySEM: cjvanlissa/tidySEM#109

Apparently, lavaan accepts numeric grouping variables, which strikes me as a mistake because numeric can have infinite and fractional values. I guess you internally convert to factor? Do you think a message or warning might be in order?

Best,
Caspar

[TDJorgensen]

Are you referring to variables passed to group= or cluster= arguments? Such groups are often represented in data sets with arbitrary numeric IDs, so I would hesitate to create errors that aren't strictly necessary. Internally, lavaan just assigns integers to unique values (even integers!) of that variable anyway. Here is an example using age (at least, ages with sufficient N to prevent an error) as a grouping variable:

HS1215 <- HolzingerSwineford1939[HolzingerSwineford1939$ageyr > 11 & HolzingerSwineford1939$ageyr < 16, ]
fit <- cfa(HS.model, data = HS1215, group = "ageyr") # doesn't converge, but no error
class(parTable(fit)$group) # "integer"
parTable(fit)$group # 1:4

But lavaan keeps track of what original values (in the data=) those integers correspond to:

lavInspect(fit, "group.label") # "13"  "12"  "14"  "15"

So reproducing the data extract from lavaan can simply assign integers, or additionally convert the integers to a factor() with labels = lavInspect(fit, "group.label").

Judging from the syntax in your linked issue, I'm not sure how the error could be avoided even if group= is a "character" variable, depending how graph_sem() extracts data from the lavaan-class object. If you let us know (e.g., link to a line in your source code) where the issue occurs, perhaps we can think along.

[cjvanlissa]

@TDJorgensen thanks for your response - I understand how lavaan handles this, and that it's common practice for people to represent cluster membership using ID numbers, but that doesn't mean those are real/floating point numbers and should be treated as such. numeric is a floating point datatype designed to handle values in $\mathbb{R}$, where you basically shouldn't have identical values except within rounding error, while groups and clusters by definition always come from a finite discrete set, i.e. factor data type. I'm questioning whether it's sensible to allow people to pass real numbers for group membership.

[yrosseel]

I had a look at the original problem. I tried to force the zyg variable to be of type integer:

dataset$zyg <- as.integer(dataset$zyg)

but the error (when calling get_edges() or get_nodes()) still persists?

Many people will use type 'numeric' to specify group (or cluster) levels, in particular if they generate the dataset themselves. They may use something like

group <- rep(c(1,2), each = 20)

while they should in principle use

group <- rep(c(1L,2L), each = 20)

to enforce type 'integer'.

But usually, that should not matter (for lavaan). I could imagine that a user may inadvertently pass a numeric vector with fractional numbers to the group/cluster argument of lavaan, and this will certainly lead to trouble. All the unique numbers will be handled as a different category/cluster, and many of them will only have a single observation, leading immediately to error messages and a hard stop.

But I could also imagine a scenario where the 'groups' are defined by a score on a test, which may be fractional. So we may have, say, 6 groups with values 0, 0.2, 0.4, 0.6, 0.8 and 1.0. If those values are used in the group/cluster argument, and they are of type 'numeric', then lavaan will simply convert them to 6 integers (1-2-3-4-5-6) and retain the labels ("0", "0.2", and so on) to be shown in the summary output. I don't see the harm in that.