Last updated: 2019-07-12
Checks: 6 0
Knit directory: FLASHvestigations/
This reproducible R Markdown analysis was created with workflowr (version 1.2.0). The Report tab describes the reproducibility checks that were applied when the results were created. The Past versions tab lists the development history.
Great! Since the R Markdown file has been committed to the Git repository, you know the exact version of the code that produced these results.
Great job! The global environment was empty. Objects defined in the global environment can affect the analysis in your R Markdown file in unknown ways. For reproduciblity it’s best to always run the code in an empty environment.
The command set.seed(20180714) was run prior to running the code in the R Markdown file. Setting a seed ensures that any results that rely on randomness, e.g. subsampling or permutations, are reproducible.
Great job! Recording the operating system, R version, and package versions is critical for reproducibility.
Nice! There were no cached chunks for this analysis, so you can be confident that you successfully produced the results during this run.
Great! You are using Git for version control. Tracking code development and connecting the code version to the results is critical for reproducibility. The version displayed above was the version of the Git repository at the time these results were generated.
Note that you need to be careful to ensure that all relevant files for the analysis have been committed to Git prior to generating the results (you can use wflow_publish or wflow_git_commit). workflowr only checks the R Markdown file, but you know if there are other scripts or data files that it depends on. Below is the status of the Git repository when the results were generated:
Ignored files:
Ignored: .DS_Store
Ignored: .Rhistory
Ignored: .Rproj.user/
Ignored: analysis/.DS_Store
Ignored: code/.DS_Store
Ignored: code/flashier_bench/.DS_Store
Ignored: data/flashier_bench/
Untracked files:
Untracked: code/ebspca.R
Note that any generated files, e.g. HTML, png, CSS, etc., are not included in this status report because it is ok for generated content to have uncommitted changes.
These are the previous versions of the R Markdown and HTML files. If you’ve configured a remote Git repository (see ?wflow_git_remote), click on the hyperlinks in the table below to view them.
| File | Version | Author | Date | Message |
|---|---|---|---|---|
| Rmd | 886de0c | Jason Willwerscheid | 2019-07-12 | wflow_publish(“analysis/squarem_notes.Rmd”) |
SQUAREM and DAAREM require two functions, both of which operate on the same set of parameters: one (the “fixed-point” function) updates the parameters according to (for example) an EM algorithm; the other calculates the value of the objective function for a given set of parameter values.
In our EBMF implementations, these steps are not distinguishable. Part of the objective (the KL divergence between prior and posteriors) falls out from the parameter updates, and it’s not currently possible to calculate the objective for arbitrarily proposed parameter values.
To use acceleration, we’d need to calculate the KL divergence directly. We could do this for point-normal prior families provided that we updated ebnm to be able to return the full posteriors (not just the first and second moments): see here. The calculations for ash prior families are probably too complicated.
So it might be possible to accelerate backfits when prior families are point-normal. The parameter set would be the priors on loadings, the full posterior for each loading, and the residual variance. The fixed-point function would do a single backfit iteration (ideally in parallel, but then monotonicity is no longer guaranteed). This would essentially have to be a complete iteration as it is implemented in flashier. Only the final step (calculating the objective) can be skipped, but we basically get the objective for free after we’ve updated everything else.
Finally, the objective function would calculate KL divergences directly and then also calculate expected squared residuals. The last step is almost prohibitively expensive when the residual variance is not assumed to be constant across all entries (the reasons are the same as those described here).
So we are restricted to the case where prior families are point-normal and var.type = 0, and even in this case we are forced to repeat the expensive step of calculating expected squared residuals when doing a fixed-point (EM) iteration. Any benefits provided by acceleration would need to outweigh this cost.
To be more precise, each DAAREM iteration does a fixed-point iteration, calculates the objective, proposes a new set of parameter values by accelerating, and calculates the objective for these new values. Assuming the worst – that the cost of the fixed-point iteration is dominated by calculating expected squared residuals – one DAAREM iteration would have the same cost as three flashier iterations.
So acceleration would need to cut the total number of iterations needed by up to a factor of three. It’s possible that this would occur – the DAAREM paper claims that acceleration can reduce the number of iterations by two or even three orders of magnitude.
Do note, however, that more than \(3k(n + p)\) parameters need to be estimated to fit an EBMF model with point-normal prior families, and backfits only really become slow when both \(n\) and \(p\) are at least 10,000 and \(k\) is greater than, say, 10. In contrast, the largest problem tested by the authors of the DAAREM paper has less than 1000 parameters. Further, when the number of EM iterations required for convergence (without acceleration) is less than 1000, as it is for EBMF in my experience, the speedups obtained by DAAREM are much less impressive (on the order of 10 or 20).
So it’s far from clear that acceleration would provide a significant speedup, and given the limitations on the kinds of situations in which it could be applied, I don’t think it’s worth the hassle of implementing it.
sessionInfo()R version 3.5.3 (2019-03-11)
Platform: x86_64-apple-darwin15.6.0 (64-bit)
Running under: macOS Mojave 10.14.5
Matrix products: default
BLAS: /Library/Frameworks/R.framework/Versions/3.5/Resources/lib/libRblas.0.dylib
LAPACK: /Library/Frameworks/R.framework/Versions/3.5/Resources/lib/libRlapack.dylib
locale:
[1] en_US.UTF-8/en_US.UTF-8/en_US.UTF-8/C/en_US.UTF-8/en_US.UTF-8
attached base packages:
[1] stats graphics grDevices utils datasets methods base
loaded via a namespace (and not attached):
[1] workflowr_1.2.0 Rcpp_1.0.1 digest_0.6.18 rprojroot_1.3-2
[5] backports_1.1.3 git2r_0.25.2 magrittr_1.5 evaluate_0.13
[9] stringi_1.4.3 fs_1.2.7 whisker_0.3-2 rmarkdown_1.12
[13] tools_3.5.3 stringr_1.4.0 glue_1.3.1 xfun_0.6
[17] yaml_2.2.0 compiler_3.5.3 htmltools_0.3.6 knitr_1.22