lavTech() and lavInspect()
Paolo Ghisletta
Hello,
I think this was already discussed some years ago, but I wonder whether some modifications are planned in the future.
The lavTech() and lavnspect() commands are incredibly useful to check that a user correctly specified the model. In some SEM software (e.g., LiSRel) this appears by default in the output, before any results, so as to immediately prompt the careful reader in case of model specification mistakes.
At present, it seems to me that the lavTech() command uses two rationales for numbering the model parameters:
- without the same number for parameters that are (by the user’s choice) constrained to be equal (e.g., in the $lambda matrix the use of equality on the factor loadings has no effect on the numbering, which to me is highly misleading)
- with the same number for parameters that are (by default) constrained to be equal (e.g., in the $psi matrix, which, because it is symmetric, has same values above and below the main diagonal)
Would it not be best to settle on a single rationale, preferably the latter, so that the user can immediately check all parameter specifications of the model, including those constrained to equality? (This is I believe the choice for Mplus, AMOS, LiSRel, OpenMx and sem in R, SAS PROC CALIS). And in that case, it would also follow that the Number of model parameters in the summary() command would be adjusted accordingly (at present it counts the parameters constrained to equality independently, the same as if they were not constrained to equality). The degrees of freedom are adjusted, although when one simply computes (number of initial elements – number of parameters), the result will not equal the df, whenever parameter equality constraints are applied (one has to additionally add the number of equality constraints).
I seem to remember that there was a fundamental logic by the lavaan conceiver(s) for counting not once, but twice, two estimated parameters that are constrained to equality, in which case my reasoning above would contradict that. Perhaps then this suggestion could be implemented with an option like “display.equality.constraints = TRUE” (or something simpler and shorter; which, by default would remain at FALSE and thus not implement a modification wrt to the present situation).
Many thanks and kindest regards,
Yves Rosseel
The logic is described here:
https://lavaan.ugent.be/notes/lavaan_eq_constraints.pdf
In addition, lavInspect(fit) prints a 'Note' on the top showing the
equality constraints. For example:
library(lavaan)
example(cfa)
fit <- cfa(HS.model, data = HolzingerSwineford1939, group = "school",
group.equal = c("loadings", "intercepts"))
lavInspect(fit)
Note: model contains equality constraints:
lhs op rhs
1 1 == 31
2 2 == 32
3 3 == 33
4 4 == 34
5 5 == 35
6 6 == 36
7 22 == 52
8 23 == 53
9 24 == 54
10 25 == 55
11 26 == 56
12 27 == 57
13 28 == 58
14 29 == 59
15 30 == 60
(when using lavTech(), the note is an attribute showing at the bottom).
In my humble opinion, this 'logic' has several benefits. It avoids the
distinction between 'simple' and 'other' (linear) equality constraints.
This implies correct eg modification indices, as shown by lavTestScore().
If the model only contains 'simple' equality constraints, I can see that
one may prefer another logic, where we 'count' the unique parameters
only. But in models with a mixture of 'simple' and other (linear)
equality constraints, I prefer a unified approach. It also provides a
clear strategy to compute the degrees-of-freedom: we can use the rank of
the constraint matrix.
That is also why the summary() of lavaan talks about the 'Number of
model parameters' (not 'free' parameters). That is also how I see the
model above: there are 63 model parameters. But on top of that, we
impose (15) equality constraints.
Yves.
On 11/12/21 11:19, Paolo Ghisletta wrote:
> Hello,
>
> I think this was already discussed some years ago, but I wonder whether
> some modifications are planned in the future.
>
> The lavTech() and lavnspect() commands are incredibly useful to check
> that a user correctly specified the model. In some SEM software (e.g.,
> LiSRel) this appears by default in the output, before any results, so as
> to immediately prompt the careful reader in case of model specification
> mistakes.
>
> At present, it seems to me that the lavTech() command uses two
> rationales for numbering the model parameters:
>
> of equality on the factor loadings has no effect on the numbering,
> which to me is highly misleading)
> is symmetric, has same values above and below the main diagonal)
>
> Would it not be best to settle on a single rationale, preferably the
> latter, so that the user can immediately check all parameter
> specifications of the model, including those constrained to equality?
> (This is I believe the choice for Mplus, AMOS, LiSRel, OpenMx and sem in
> R, SAS PROC CALIS). And in that case, it would also follow that the
> Number of model parameters in the summary() command would be adjusted
> accordingly (at present it counts the parameters constrained to equality
> independently, the same as if they were not constrained to equality).
> The degrees of freedom are adjusted, although when one simply computes
> (number of initial elements – number of parameters), the result will not
> equal the df, whenever parameter equality constraints are applied (one
> has to additionally add the number of equality constraints).
>
> I seem to remember that there was a fundamental logic by the lavaan
> conceiver(s) for counting not once, but twice, two estimated parameters
> that are constrained to equality, in which case my reasoning above would
> contradict that. Perhaps then this suggestion could be implemented with
> an option like “display.equality.constraints = TRUE” (or something
> simpler and shorter; which, by default would remain at FALSE and thus
> not implement a modification wrt to the present situation).
>
> Many thanks and kindest regards,
>
> 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
> <mailto:lavaan+un...@googlegroups.com>.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/lavaan/000001d7d7ae%24d967aa50%248c36fef0%24%40gmail.com
> <https://groups.google.com/d/msgid/lavaan/000001d7d7ae%24d967aa50%248c36fef0%24%40gmail.com?utm_medium=email&utm_source=footer>.