Skip to content

Commit d01b222

Browse files
committed
update and version bump
1 parent e1efb4d commit d01b222

File tree

2 files changed

+30
-2
lines changed

2 files changed

+30
-2
lines changed

DESCRIPTION

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -1,6 +1,6 @@
11
Package: SimDesign
22
Title: Structure for Organizing Monte Carlo Simulation Designs
3-
Version: 2.6.5
3+
Version: 2.7
44
Authors@R: c(person("Phil", "Chalmers", email = "[email protected]", role = c("aut", "cre"),
55
comment = c(ORCID="0000-0001-5332-2810")),
66
person("Matthew", "Sigal", role = c("ctb")),

vignettes/MultipleAnalyses.Rmd

Lines changed: 29 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -57,7 +57,7 @@ The above template should of course be modified to replace the less useful names
5757
Finally, note that all the rules about objects and object naming from the typical single Analyse function still apply and are properly checked internally for suitable names and consistency. The independently defined Analyse functions are also *interchangable* and *removable*/*replaceable*, which makes the structure of the Generate-Analyse-Summarise setup more modular with respect to the analysis components.
5858

5959

60-
# An example
60+
## An example
6161

6262
The following code is [adopted from the Wiki](http://philchalmers.github.io/SimDesign/html/03-Parameter_recovery_simulation.html), and so details about the simulation should be obtained from that source.
6363

@@ -578,3 +578,31 @@ Analyse.FIML <- function(condition, dat, fixed_objects = NULL) {
578578

579579
Using this definition the final object returned by `runSimulation()` will provide suitable `NA` placeholders (where appropriate). For continuous indicators the results will be presented as though `mirt` was never used for the continuous indicator conditions controlled by the `Design` object.
580580

581+
## Applying one analyse function per-condition
582+
583+
Interestingly, `AnalyseIf()` could also be used to select only one analysis function at a time given the components in the `Design` object. For instance, if the `Design` definition were constructed using
584+
585+
```{r}
586+
Design <- createDesign(sample_size = sample_sizes,
587+
nitems = nitems,
588+
method = c('FIML', 'DWLS'))
589+
Design
590+
```
591+
592+
and the analysis functions above were supplied defined as
593+
594+
```{r}
595+
Analyse.FIML <- function(condition, dat, fixed_objects = NULL) {
596+
AnalyseIf(method == 'FIML', condition)
597+
#...
598+
}
599+
600+
Analyse.DWLS <- function(condition, dat, fixed_objects = NULL) {
601+
AnalyseIf(method == 'DWLS', condition)
602+
# ...
603+
}
604+
```
605+
606+
then only one analysis function will be applied at a time in the simulation experiment. Users may find this a more natural setup than having to merge all analysis information into a single `Analyse()` definition. The downside, however, is that the analysis function will be applied to different generated datasets, which while theoretically unbiased could have ramifications should the analysis functions throw errors at different rates (even when explicitly supplying a `seed` vector input to `runSimulation()`).
607+
608+

0 commit comments

Comments
 (0)