PLS-SEM GitHub issues

[juliuspfadt]

fixes https://github.com/jasp-stats/INTERNAL-jasp/issues/2725
fixes https://github.com/jasp-stats/jasp-test-release/issues/2829
fixes https://github.com/jasp-stats/INTERNAL-jasp/issues/2772
fixes https://github.com/jasp-stats/INTERNAL-jasp/issues/2771
fixes https://github.com/jasp-stats/INTERNAL-jasp/issues/2729
fixes https://github.com/jasp-stats/INTERNAL-jasp/issues/2727
fixes https://github.com/jasp-stats/INTERNAL-jasp/issues/2726
fixes https://github.com/jasp-stats/INTERNAL-jasp/issues/2728

[juliuspfadt]

@kylelang, can you review? I worked with @FloSchuberth to address all the issues, he is the developer of the underlying R-package.

[kylelang]

@kylelang, can you review? I worked with @FloSchuberth to address all the issues, he is the developer of the underlying R-package.

I'll take a look next week.

[juliuspfadt]

@kylelang How are we doing with this?

[kylelang]

Sorry about the delay. At least on my system, half of these fixes work, but there are still problems with the benchmark options and the multiple group construct scores. See my itemized comments below.

fixes https://github.com/jasp-stats/INTERNAL-jasp/issues/2725

• Agree

fixes https://github.com/jasp-stats/jasp-test-release/issues/2829

• Technically, this fixes the bug, but the solution doesn't feel very satisfying.
• The new error message doesn't explain why covariances aren't allowed.
• It's pretty strange to suggest naively replacing all covariances with regression paths.
• If the user understands their model and has specified covariances for a reason, they'll think you're crazy.

fixes https://github.com/jasp-stats/INTERNAL-jasp/issues/2772

• I can't evaluate this change. I wasn't aware of the original problem, and the linked issue doesn't document the putative bug.

fixes https://github.com/jasp-stats/INTERNAL-jasp/issues/2771

• Same as above.

fixes https://github.com/jasp-stats/INTERNAL-jasp/issues/2729

• The original bug is no longer possible since the offensive option has been removed, but a new bug has taken up residence.
• Setting the benchmark option to "all" now crashes the analysis with an archaic R error.
• You can reproduce the new bug by following the same steps that triggered the original bug but setting the benchmark option to "all".
• MRE

fixes https://github.com/jasp-stats/INTERNAL-jasp/issues/2727

• This one still seems to be determinedly broken, although now in new and exciting ways.
• Asking to save the construct scores in a multiple group model will cause the analysis to rerun in an infinite loop.
• The behavior feels like a broken JASP container dependency.
• MRE.

fixes https://github.com/jasp-stats/INTERNAL-jasp/issues/2726

• Agree

fixes https://github.com/jasp-stats/INTERNAL-jasp/issues/2728

• Agree

[juliuspfadt]

fixes jasp-stats/jasp-test-release#2829

• Technically, this fixes the bug, but the solution doesn't feel very satisfying.
• The new error message doesn't explain why covariances aren't allowed.
• It's pretty strange to suggest naively replacing all covariances with regression paths.
• If the user understands their model and has specified covariances for a reason, they'll think you're crazy.

@FloSchuberth had some insight as to why it was not a good idea to allow these covariances. I think we may need a better error message.

fixes jasp-stats/INTERNAL-jasp#2772

This had something with multiple models, but I removed the option to specify multiple models, because there was little benefit for this specific analysis.

fixes jasp-stats/INTERNAL-jasp#2771

this was changing the format of some p-values in tables.

fixes jasp-stats/INTERNAL-jasp#2729

• The original bug is no longer possible since the offensive option has been removed, but a new bug has taken up residence.
• Setting the benchmark option to "all" now crashes the analysis with an archaic R error.

Fixed that now.

fixes jasp-stats/INTERNAL-jasp#2727

• This one still seems to be determinedly broken, although now in new and exciting ways.
• Asking to save the construct scores in a multiple group model will cause the analysis to rerun in an infinite loop.
• The behavior feels like a broken JASP container dependency.
  I did some digging but I cannot seem to find the error. I think I will wait to have the preloadData functionality ready for this module, and then see if the updated dataset has something to do with this.

[FloSchuberth]

Considering the covariances. In PLS-PM you cannot specify covariances as you can do in SEM. PLS-PM is a two-step procedure. In the first step, the correlations between the constructs are estimated. This is similar to fitting a CFA model (similar because by default PLS-PM works with composites). In the second step, this correlation matrix is used as input for OLS to estimate the structural model. Therefore, it is not possible to specify covariances as we can do in SEM. Does that help?

[kylelang]

Considering the covariances. In PLS-PM you cannot specify covariances as you can do in SEM. PLS-PM is a two-step procedure. In the first step, the correlations between the constructs are estimated. This is similar to fitting a CFA model (similar because by default PLS-PM works with composites). In the second step, this correlation matrix is used as input for OLS to estimate the structural model. Therefore, it is not possible to specify covariances as we can do in SEM. Does that help?

This makes sense. Does the same restriction apply to correlated residuals for reflective factors in the model? That is, are all covariances impossible in a PLS-SEM, or is it only covariances in the structural model that aren't allowed? If some covariances are possible, triggering an error anytime the syntax contains ~~ would be overly restrictive, right?

[FloSchuberth]

@kylelang: Traditionally, correlated errors are not possible in PLS-PM. The reason for this is that PLS just creates composites as proxies for the latent variables. To address this issue consistent partial least squares (PLSc) has been developed. You can think about PLSc as an approach similar to factor score regression. PLSc can consistently estimate factor laodings and path coefficients of models following the so-called basic design, i.e., models with no cross-loadings, no correlated errors, no feedback loops etc. Recently, we proposed a way how PLSc can be applied to models where random measurement errors are correlated within a block of indicators (indicators that belong to the same latent variable; https://www.emerald.com/insight/content/doi/10.1108/intr-12-2017-0525/full/html). This approach is also implemented in cSEM. Therefore, in principle it is possible to use the ~~ operator in some situations. However, to the best of my knowledge cSEM is the only software where this approach is implemented. Moreover, I believe that correlated errors are not much of interest to the normal PLS user.

Long story short: Not all covariances are impossible since correlated error terms between indicators belonging to one latent variable can be taken into account. This approach is also implemented in cSEM.

[juliuspfadt]

Thanks for clarifying Flo. The question that remains is if we want to allow that then only for residuals, or prevent it for everything.

[FloSchuberth]

@juliuspfadt I think when we discussed the implementation of PLS-PM in JASP we decided to prohibit specifying covariances for the sake of keeping things simple. I have no preferences. However, if you allow for these covariances, they should also be reported in the parameter table,

[juliuspfadt]

So right now I am trying to get the preloadData stuff to work, but there are some hiccups. Eventually, I hope this will help me fix the infinite loop error. I am also trying to get the residual covariances into a table, but I am not certain where in the output I would find them @FloSchuberth ?

[juliuspfadt]

It seems I could just take them out of Estimates$Residual_correlation at the index of the two variables that are involved? But does that mean all residual correlations are estimated anyways at all times?

[FloSchuberth]

@juliuspfadt:
In PLS, all variables are standardized before the analysis. Under Estimates$Residual_correlation, we always store S - Lambda%*%t(Lambda), where S is the sample correlation matrix and Lambda is the loading matrix (which can can in principle contain composite and factor loadings). Note that in PLS it is not possible to specify cross-loadings.

If you specify measurement error correlations, i.e., you specify a latent variable using =and you specify the correlation between measurement error within a block of indicators using ~~, PLSc (i.e., I assume that you correct for attenuation) will take this information into account during the estimation of the correction factor used to obtain the factor loading estimates. Consequently, the corresponding entry in Estimates$Residual_correlation shows the measurement error correlation. However, be aware that users can easily wrongly apply the ~~ operator. For example they can use it in combination with a composite (<) or using traditional PLS instead of PLSc (i.e., not correcting for attenuation). In this case, the correlation is misleading. Unfortunately, we have currently no checks in place to prevent this.