Using bounds and optim.bound to constrain the range of parameter estimation

[Fabrício Fialho]

Hi all,  

Hope you're all well. 

I have a few questions on the `bounds` and `optim.bounds` arguments in lavOptions() for an application. Per my understanding of lavaan's help file, both commands would enlarge the range of the bounds of the parameters. Is it possible to somehow restrict the bounds? I ask so because I have tried, without much success, bounds="pos.ov.var" to force "observed variances" to be nonnegative, assuming this means the residual variances would be nonnegative. 

I have been successfully replicating a model (with categorical observed variables loading on two factors) in multiple groups using data from multiple years except for one group in one specific year, where residual variance for one sole variable tends to be negative (the variable is categorical, latent variate y* variance is set to one, and the estimated factor loading is slightly above one, ~1.1). The number of observations for the group is large enough (700+) to presume the residual variance is not due to sampling fluctuation. 

In order to investigate the issue, among other things, I've played with different values for bounds and optim.bounds trying either to set an upper cap for the said factor loading or to prevent the residual variance to go negative, without much success. Are bounds and optim.bounds appropriate for what I am trying to do here? 

Overall, I would appreciate further info on how to use bounds and optim.bounds and what the arguments can/should do. This is my first run with them and I am eager to learn more about this feature! 

Best wishes,

Fabricio

[Terrence Jorgensen]

I have tried, without much success, bounds="pos.ov.var" to force "observed variances" to be nonnegative

That is not recommended

https://doi.org/10.1177/0049124112442138

But lavaan's model syntax does accept inequality constraints for labeled parameters.

mod <- ' fac =~ x1 + x2 + x3

  x1 ~~ resvar1*x1 # label residual variance

  resvar1 > 0      # inequality constraint

'

Terrence D. Jorgensen

Assistant Professor, Methods and Statistics

Research Institute for Child Development and Education, the University of Amsterdam

http://www.uva.nl/profile/t.d.jorgensen

 

[Fabrício Fialho]

Hi Terrence,

Thanks for your feedback. 

Yes, lavaan's model syntax is powerful and straightforward in the use of labeled parameters to impose equality and inequality constraints. 

Please allow me to clarify the matter:

In the investigation of the possible cause(s) of negative residual variance in one variable, I have tried solutions equivalent to your example but lavaan has nevertheless returned negative residual variance even when it is is constrained > 0 if bounds="none" (lavaan default); the same negative residual variance happened even if constrained == 0. 

If bounds="standard", the residual variance is nonnegative but factor variance is constrained to equality between groups (even though factor variance is explicitly allowed to differ between groups in the model syntax). That's the reason of the query on `bounds` and `optim.bounds`.

Issues with constrained parameter estimation are well known (e.g.  Savalei & Kolenikov 2008; Kolenikov & Bollen 2012). The aim is just to investigate what might be happening with this group in this specific survey, using a range of options, for referees may inquiry about this negative variance parameter for this one group-year -- which is not unexpected given the SEMNET skirmishes on the causes of negative residual variance.

Best,

Fabricio

[Yves Rosseel]

One big caveat here is that if you use (linear) equality constraints,
the bounds do not work any more.

(The reason is that in the presence of linear equality constraints, the
constrained parameter vector is projected to a smaller but unconstrained
parameter vector; this is very efficient, but the bounds no longer have
any meaning in this projected space)

Yves.

On 8/25/21 1:09 AM, Fabrício Fialho wrote:
> Hi all,
>
> Hope you're all well.
>
> I have a few questions on the `bounds` and `optim.bounds` arguments in
> lavOptions() for an application. Per my understanding of lavaan's help
> file, both commands would enlarge the range of the bounds of the

> parameters. Is it possible to somehow /restrict/ the bounds? I ask so

> because I have tried, without much success, bounds="pos.ov.var" to force
> "observed variances" to be nonnegative, assuming this means the residual
> variances would be nonnegative.
>
> I have been successfully replicating a model (with categorical observed
> variables loading on two factors) in multiple groups using data from
> multiple years except for one group in one specific year, where residual
> variance for one sole variable tends to be negative (the variable is
> categorical, latent variate y* variance is set to one, and the estimated
> factor loading is slightly above one, ~1.1). The number of observations
> for the group is large enough (700+) to presume the residual variance is

> /not/ due to sampling fluctuation.

> In order to investigate the issue, among other things, I've played with
> different values for bounds and optim.bounds trying either to set an
> upper cap for the said factor loading or to prevent the residual
> variance to go negative, without much success. Are bounds and
> optim.bounds appropriate for what I am trying to do here?
>
> Overall, I would appreciate further info on how to use bounds and
> optim.bounds and what the arguments can/should do. This is my first run
> with them and I am eager to learn more about this feature!
>
> Best wishes,
> Fabricio
>

> --
> 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/82b74673-ddf7-4709-9ab3-9ee6f01d661en%40googlegroups.com
> <https://groups.google.com/d/msgid/lavaan/82b74673-ddf7-4709-9ab3-9ee6f01d661en%40googlegroups.com?utm_medium=email&utm_source=footer>.