Tidying for latest developments

.Rbuildignore

@@ -15,3 +15,4 @@ inst/Chemotherapy_Book/.RData
 inst/Chemotherapy_Book/.git
 ^_pkgdown2\.yml$
 git_notes.md
+coding_style.md

DESCRIPTION

@@ -1,6 +1,6 @@
 Package: voi
 Title: Expected Value of Information 
-Version: 0.1
+Version: 0.9
 Authors@R: 
     c(person(given = "Christopher", family = "Jackson",role = c("aut", "cre"),email = "chris.jackson@mrc-bsu.cam.ac.uk"),
 	   person(given = "Anna", family = "Heath", role = c("aut"), email = "anna.heath@sickkids.ca"),
@@ -16,7 +16,7 @@ LazyData: true
 Depends: R (>= 2.10)
 VignetteBuilder: knitr
 Imports: mgcv, earth, mvtnorm, progress, dbarts, posterior, ggplot2, gridExtra
-Suggests: testthat, BCEA, INLA, splancs, knitr, rmarkdown, rjags, truncnorm, scales, dplyr
+Suggests: testthat, BCEA, INLA, splancs, knitr, rmarkdown, rjags, truncnorm, scales, dplyr, heemod
 RoxygenNote: 7.2.3
 Roxygen: list(markdown = TRUE)
 URL: https://chjackson.github.io/voi/

NAMESPACE

@@ -16,6 +16,8 @@ export(evppi_mc)
 export(evppivar)
 export(evsi)
 export(evsivar)
+export(import_heemod_inputs)
+export(import_heemod_outputs)
 export(pop_voi)
 importFrom(ggplot2,aes)
 importFrom(ggplot2,geom_histogram)

R/check_regression.R

@@ -66,8 +66,6 @@
 ##' 
 ##' @export
 check_regression <- function(x, pars=NULL, n=NULL, comparison=1, outcome="costs", plot=TRUE){
-  ## TODO check for evsi vs evppi here.
-  ## then treat n in evsi like pars in evppi 
   if (inherits(x, "evppi")) {
     if (is.null(pars)) pars <- x$pars[1]
     if (!(pars %in% x$pars)) stop(sprintf("parameter `%s` not found", pars))

R/evppi_mc.R

@@ -97,7 +97,6 @@ evppimc.nb <- function(model_fn, par_fn, pars, pars_rep, nouter, ninner, nopt, w
     nf <- names(formals(model_fn))
     defaults <- get_default_args(model_fn, pars_rep)   
     pars_corr <- intersect(names(formals(par_fn)), nf)
-#    registerDoParallel() # TODO 
     pb <- progress::progress_bar$new(total = nouter) 
     for (i in 1:nouter){
         nbi <- matrix(nrow=ninner, ncol=nopt)

R/model_chemo_wrapper.R

@@ -4,7 +4,7 @@
 ##' Functions are provided to generate model parameters and evaluate the model, and samples from probabilistic analysis of the model are
 ##' provided as built-in datasets.
 ##'
-##' TODO refer to VoI book for more details
+##' For more details, refer to Heath et al. (forthcoming book...)
 ##'
 ##' @param p_side_effects_t1 Probability of side effects under treatment 1
 ##' @param p_side_effects_t2 Probability of side effects under treatment 2
@@ -72,10 +72,12 @@
 ##'
 ##' The following additional data objects are supplied:
 ##' 
-##' \code{chemo_constants} includes various constants required by the code. TODO DOC
+##' \code{chemo_constants} includes various constants required by the code.
 ##'
 ##' \code{chemo_evsi_or} is the result of an EVSI analysis to estimate the expected value of a two-arm trial, with a binary outcome, to estimate the log odds ratio of side effects.  This object is a data frame with three columns, giving the sample size per arm (`n`), willingness-to-pay (`k`) and the corresponding EVSI (`evsi`).
 ##' 
+##' @references Value of Information for Healthcare Decision Making
+##' (CRC Press, eds. Heath, Kunst and Jackson: forthcoming)
 ##' 
 ##' @name chemo_model
 NULL

R/study.R

@@ -65,13 +65,12 @@ likelihood_trial_binary <- function(Y, inputs, n=100, pars){
 
 ## Single-arm study of a normal outcome with known variance (supplied as an argument) 
 ## Return an estimate of the mean from a study of size n 
-## TODO consistent naming with the vignette
 
 datagen_normal_known <- function(inputs, n=100, pars, sd=1){
-    nsim <- nrow(inputs)
-    mu <- inputs[,pars[1]]
     data.frame(
-        X1 = rnorm(nsim, mu, sd/sqrt(n))
+      X1 = rnorm(nrow(inputs),
+                 mean = inputs[,pars[1]],
+                 sd = sd/sqrt(n))
     )
 }
 

README.md

@@ -1,4 +1,4 @@
-## voi: a generic package to calculate the expected value of information
+# voi: a generic package to calculate the expected value of information
 
 * A common interface for several methods to calculate the
 
@@ -8,6 +8,38 @@
 
 * A project of the [ConVOI Group: the Collaborative Network for Value of Information](http://convoi-group.org)
 
+
+## Comparison with other packages
+
+`voi` is pure "command-based" R, with no web interface like [SAVI](http://savi.shef.ac.uk).
+
+* The R commands in `voi` are clean and consistent.  They all have the same basic interface, so you can switch between computational methods easily.
+
+* Outputs are all in "tidy" data frames for consistency, and to facilitate post-processing and plotting with modern tools such as [ggplot2](http://ggplot2.tidyverse.org). 
+
+#### EVPPI computation
+
+* `voi` includes all the EVPPI computation methods that are in [SAVI](http://savi.shef.ac.uk) (GAM and Gaussian process regression), and includes the INLA method from [BCEA](https://cran.r-project.org/package=BCEA).
+
+* Some other nonparametric regression methods (`"earth"`, `"bart"`) are included in `voi`, which may improve efficiency for multiparameter EVPPI computation problems with large numbers of parameters.
+
+#### EVSI computation
+
+* `voi` is the first package to implement a range of EVSI computation methods: nonparametric regression, moment matching and importance sampling.
+
+#### In summary 
+
+* `voi` will not benefit SAVI users that just need single-parameter EVPPI, or users that want a web interface.
+
+* `voi` will benefit you if you want to calculate EVSI, or multiparameter EVPPI with large numbers of parameters. 
+
+
+
+
+
+
+
+
 ## Installation
 
 ```

TODO.md

@@ -1,118 +1,21 @@
-## DONE
+## TODO long term 
 
-* Basic package structure
+* More built-in common study designs for EVSI, e.g. binary trial that just informs the odds ratio.
 
-* EVPPI methods copied in from BCEA/SAVI and tidied up
+* Different regression methods and options for effects and costs (e.g. int.ord)
 
-* A few unit tests added for these 
 
-* Nonparametric regression and importance sampling methods added for EVSI, and rough tests written
+## Features that I don't plan to implement myself, but would accept cleanly-written contributions for (see coding_style.md) 
 
-* Study design for EVSI can be specified as an R function to simulate data from it, or as one of the built-in standard designs - currently only have 1-arm or 2 arm trials of a binary outcome. 
+* Parallel processing for 2 level Monte Carlo, and partial results for convergence checking 
 
-* Chemotherapy model code added to facilitate examples. Note exact format of this code may change as we implement different methods that need access to the decision model function. 
-
-* Standard 2-level Monte Carlo 
-
-
-## TODO
-
-* A test model with more than two decision options 
-
-EVPPI
-
-* Different regression methods and options for effects and costs
-
-* INLA: check plots work
-
-* Test earth gam method more, compare against other methods to suggest advantages, while developing book material. 
-
-* Standard errors for earth.  INLA too?
-
-* Anything to facilitate algebraic methods?
-
-* Any other plots for communication?
-
-* Use "wtp" or "k"?
+* Gaussian Approximation EVSI method
 
 * MLMC and QMC methods
 
-* Parallel processing for standard 2 level Monte Carlo, and partial results for convergence checking 
-
-
-
-EVSI
-
-* More built-in study designs - which ones? 
-
-* Any need to handle designs controlled by more than one sample size?  If so, make sure multiple arguments to datagen_fn are handled nicely
-
-* Guidance for users to specify appropriate GAM formulae for their applications when the default formula is too intensive.  Relatedly, appropriate number of PSA samples to use. 
-
-* Add Jalal EVSI method
-
-* 2-level Monte Carlo again
-
-* Output analysis material from Anna's EVSI package.
-
-
-
-GENERAL
-
-* Interface to heemod package.  Any other packages to interface with?
-
-
-
-
-## PRINCIPLES OF PACKAGE DEVELOPMENT
-
-
-### Using
-
-* Most important!
-
-* Just use it any time you want to do a VoI calculation, and give feedback.
-Describe what you had to do to make it work in your example.  If you need to do anything tedious, this may suggest how the package could be more helpful.
-
-* Does other software do anything better?
-
-
-### Design
-
-* Decide what the package should do, and what is better done with other tools
-
-* What functions should look like: argument formats, consistency between different parts of the code
-
-* Identifying where we do the same task multiple times, therefore should have a function for that task
-
-
-### Coding 
-
-* Clean, modular and consistent style.  Each function does one thing that can be described concisely.
-
-* Descriptive/concise variable and function names.
-
-* Code should be understandable as much as possible by itself without the need for commenting.
-
-* Comment in cases where it won't be instantly obvious what the code is doing. 
-
-* Any time you add code, add a unit test - a concise example where that code is executed - to ensure that test gives the expected result every time the code is modified. 
-
-* House style: 
-
-	- underscores not dots to separate words in function or variable names:  `my_variable_name`
-
-	- use spaces to clearly separate elements of code, e.g. 
-       `x <- fn(a, b, c)`  is much easier to read than  `x<-fn(a,b,c)` 
-
-
-
-### Documentation 
-
-* Vignettes with worked examples
+* 2-level Monte Carlo EVSI
 
 * Check can reproduce results from ConVoI 1 four case studies
 
-* Any new ConVoI examples (book, papers) should come with code to do them with this package. 
+* Standard errors for EVSI methods and INLA EVPPI method 
 
-* Note these may raise "further research is needed" questions!

_pkgdown.yml

@@ -19,6 +19,7 @@ reference:
   - pop_voi
 - title: Utilities
 - contents:
+  - import_heemod
   - all_interactions
   - check_regression
 - title: Example decision models

coding_style.md

@@ -0,0 +1,39 @@
+## PRINCIPLES OF PACKAGE DEVELOPMENT
+
+
+### Using
+
+* Most important!
+
+* Just use it any time you want to do a VoI calculation, and give feedback.  Describe what you had to do to make it work in your example.  If you need to do anything tedious, this may suggest how the package could be more helpful.
+
+* Does other software do anything better?
+
+
+### Design
+
+* Decide what the package should do, and what is better done with other tools
+
+* What functions should look like: argument formats, consistency between different parts of the code
+
+* Identifying where we do the same task multiple times, therefore should have a function for that task
+
+
+### Coding 
+
+* Clean, modular and consistent style.  Each function does one thing that can be described concisely.
+
+* Descriptive/concise variable and function names.
+
+* Code should be understandable as much as possible by itself without the need for commenting.
+
+* Comment in cases where it won't be instantly obvious what the code is doing. 
+
+* Any time you add code, add a unit test - a concise example where that code is executed - to ensure that test gives the expected result every time the code is modified. 
+
+* House style: 
+
+	- underscores not dots to separate words in function or variable names:  `my_variable_name`
+
+	- use spaces to clearly separate elements of code, e.g. 
+       `x <- fn(a, b, c)`  is much easier to read than  `x<-fn(a,b,c)`