simsem / semTools

Useful tools for structural equation modeling
75 stars 36 forks source link

Adding emmean support #70

Closed mattansb closed 4 years ago

mattansb commented 4 years ago

WIP #69

TDJorgensen commented 4 years ago

Hi Mattan,

Sorry for the delay; I'm sure the pandemic interrupted your life as well. I also had a son last month :-)

I just made some updates to semTools, some of which are related to R 4.0, and semTools now relies on the latest lavaan 0.6-6. I am about to merge your PR and make some minor changes:

I'll let you know if I have any other questions, but it looks like it will merge fine, even though you were working with an older DESCRIPTION file. Thank you for the generous work on resolving these issues! This is an excellent contribution, which I plan to use in my own teaching.

mattansb commented 4 years ago

Hey Terrence,

Congrats on you baby boy!

I'm glad to see this merged (will probably use this next time teaching lavaan). Please let me know if there's anything else I can do.

Great working with you (:

Mattan

TDJorgensen commented 4 years ago

This response on StackOverflow indicated the examples subdirectory is best placed within the inst subdirectory, which resolves the CRAN check for nonstandard subdirectory names.

I also ended up just moving the multiple-group check to recover_data.lavaan(), just underneath the .emlav_test_DV() call, so the additional arguments in ... are accessible. Now the warning only prints if they actually forgot to set the nesting= argument with a multigroup model:

dots <- list(...)
if (lavInspect(object, 'ngroups') > 1L && !("nesting" %in% names(dots))) warning(...)

Just sent it to CRAN, hopefully it goes through.

mattansb commented 4 years ago

Yeah, that makes more sense (:

I think that should be

dots <- list(...)
if (lavInspect(object, 'ngroups') > 1L && !("nesting" %in% names(dots) && is.null(dots$nesting))) warning(...)

Just in case any other nesting values (that is not NULL) is passed by the user.

TDJorgensen commented 4 years ago

I decided against checking is.null because groups could possibly have models that contain different effects (even different variables, by specifying syntax in blocks). So nested effects still are possible, although I’m sure unlikely in practice.