standardized parameters don't match between std.lv = T and std.lv = F

36 views
Skip to first unread message

Luisa Horsten

unread,
Aug 19, 2019, 9:18:50 AM8/19/19
to lavaan
Dear all,
I use SEM to test hypotheses concerning the relation between latent factors. Say my model looks like this:

bifactor <- '
A =~ X1 + X2 + X3 + X4 + X5 + X6
B =~ X7 + X8 + X9 + X10 + X11 + X12
C =~ X13 + X14 + X15 + X16 + X17 + X18


G =~ X1 + X2 + X3 + X4 + X5 + X6 + X7 + X8 + X9 + X10 + X11 + X12 + X13 + X14 + X15 + X16 + X17 + X18



D =~ X19 + X20 + X21 + X22 + X23 + X24
H =~ Y1 + Y2 + Y3 + Y4 + Y5 + Y6


D ~~ HH
D ~~ G'


My approach so far was to estimate one model in which the parameters are estimated freely and then one in which I constrain the parameters to be equal (D ~~ a*HH, D ~~ a*G).
My hypothesis would be that r(D, G) > r(D, HH), so I want to look at the standardized parameters.Thus, when fitting the model I set std.lv = TRUE
Now I would expect that the value in the estimate and the std.lv columns are equal (which they are), and that they are also equal to the values in the std.lv-column of the fitted model, in which I did not set std.lv = TRUE. The latter is not the case and I am super confused about that. I had used the exact same approach in a model before, and there the values matched, so I feel like I am not completely off with my expectation... Could anybody shed light on this? Thanks a lot in advance!

Edward Rigdon

unread,
Aug 19, 2019, 9:29:06 AM8/19/19
to lav...@googlegroups.com
What is HH? Is it related to H?

--
You received this message because you are subscribed to the Google Groups "lavaan" group.
To unsubscribe from this group and stop receiving emails from it, send an email to lavaan+un...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/lavaan/51608bba-57be-4404-93c6-328e87f8f365%40googlegroups.com.

Terrence Jorgensen

unread,
Aug 19, 2019, 10:15:41 AM8/19/19
to lavaan
Ed's question is relevant because HH appears to be either a typo for H, or HH is an observed variable.  If it is the latter, try setting fixed.x=FALSE and comparing Std.lv columns.  Additionally, did you set orthogonal=TRUE?  

Terrence D. Jorgensen
Assistant Professor, Methods and Statistics
Research Institute for Child Development and Education, the University of Amsterdam

Message has been deleted

Luisa Horsten

unread,
Aug 20, 2019, 11:06:27 AM8/20/19
to lavaan
Oh yes, sorry, my bad. Those are good points, indeed! That was indeed a typo, H and HH are the same. And no, I did not set orthogonal = TRUE, but what I did is set A ~~ 0*B, A ~~ 0*C, A ~~ 0*G, B ~~ 0*C, B ~~ 0*G, C ~~ 0*G. Sorry, should have mentioned that from the start. So the full model is

bifactor <- '

A =~ X1 + X2 + X3 + X4 + X5 + X6
B =~ X7 + X8 + X9 + X10 + X11 + X12
C =~ X13 + X14 + X15 + X16 + X17 + X18


G =~ X1 + X2 + X3 + X4 + X5 + X6 + X7 + X8 + X9 + X10 + X11 + X12 + X13 + X14 + X15 + X16 + X17 + X18



D =~ X19 + X20 + X21 + X22 + X23 + X24
HH =~ Y1 + Y2 + Y3 + Y4 + Y5 + Y6



D ~~ HH
D ~~ G


A ~~ 0*B
 A ~~ 0*C
A ~~ 0*G
B ~~ 0*C
B ~~ 0*G
C ~~ 0*G'



bifactor
.fit <- cfa(bifactor,
                     data
= data,
                     missing
= "fiml",
                     
std.lv = TRUE,
                     estimator
= "MLR")

Terrence Jorgensen

unread,
Aug 21, 2019, 6:55:13 AM8/21/19
to lavaan
Interesting.  I just tried comparing the Std.lv column with std.lv=TRUE and FALSE using the ?cfa example, and found the same issue.  Thanks for point this out.

The problem is due to a new argument, which provides a third option to set the latent scale: effects.coding="loadings"

?lavOptions

The previous behavior set the value of auto.fix.first as the opposite of std.lv (so if one was TRUE, the other was FALSE).  Now, when you set std.lv=TRUE, it leaves auto.fix.first=TRUE.  In your output, did you notice that the latent variances were all 1, but so were all the first factor loadings?  So the reason results were inconsistent is probably that you were comparing models that were not statistically equivalent, because with std.lv=TRUE, there were additional constraints. 

For now, you can get around this by explicitly setting std.lv=TRUE and auto.fix.first=FALSE.  I will bring this to Yves' attention to update the internal checks, to make sure the original behavior automatically sets auto.fix.first=FALSE when std.lv=TRUE.  

Luisa Horsten

unread,
Aug 21, 2019, 9:38:27 AM8/21/19
to lavaan
No, to be honest I did not double check the factor loadings, but now that you mention it... :D Thanks for your time investigating this, I really appreciate it!
Reply all
Reply to author
Forward
Message has been deleted
0 new messages