Skip to contents

Active Learning Sampling Design (ALSD) R package

This R package provides an implementation of the Active Learning Sampling Design (ALSD) framework, as described in the paper “Active learning sampling design: a new adaptive survey design paradigm”. It is a refactoring of the original analysis scripts into a reusable, documented, and testable package format.

Working title is activesampling, formerly alsd and bsd.

The primary goal of ALSD is to adaptively allocate survey sampling effort to minimise the design effect (D_eff) from weighting, thereby maximising the effective sample size (n_eff) and improving the accuracy of survey estimates.

Development

This package was created by restructuring the original scripts to improve coding practices and reusability. Some things may be missing, incomplete or may have been ported incorrectly. The key changes are:

  1. Package structure: the analysis has been converted from a collection of standalone R scripts into a formal R package structure. This includes metadata files for the package description and dependency management and a folder structure with distinct directories for R code, tests, sample data and possibly tutorial/demonstration vignettes.

  2. Dependency management: the custom ADAM.R optimiser has been replaced with a call to the same function from the external optimg package. Other dependencies, like dplyr, are now formally declared in the DESCRIPTION file. Some unnecessary dependencies, such as for definitions of logit or sigmoid functions, will be removed in favour of base R equivalents.

  3. Data encapsulation: the reliance on the large and complex World Food Programme (WFP) dataset has been removed in favour of a small, synthetic example dataset, so that the package is self-contained.

  4. Testing: a minimal set of unit tests has been introduced using the testthat framework. More may be added later.

  5. Documentation and examples. All exported functions are, or will be, documented using roxygen2. A vignette is included to provide a step-by-step tutorial on how to use the package to run a simulation, replciating the core experiment (in methodology, if not in numerical results).

Installation

To install this package from the local directory, use

# install.packages('devtools')
devtools::install('path/to/activesampling')

Then, to see the main tutorial, run:

library(activesampling)
# Browse available vignettes for this package
browseVignettes('activesampling')

# Or open specific vignettes by file-base name
vignette('walkthrough', package = 'activesampling')
vignette('replication', package = 'activesampling')

Contributors

Status, caveats, and roadmap

This package is a cleaned-up reimplementation of the original scripts. It’s usable, but there are differences and some features are intentionally deferred. Key points:

  • Design effect (D_eff)
    • Expected D_eff used by the optimiser matches the paper’s Kish-based formula with S(beta), S_h(beta), W_h(beta).
    • Realized D_eff in simulation summaries uses post-stratification weights from actual respondents; weights are normalized to mean 1 and D_eff = mean(w^2) = 1 + var(w).
    • Legacy scripts sometimes report only var(w) (without +1). If comparing to legacy plots, subtract 1 from D_eff to match.
  • Selection probabilities and budget
    • Modelled method uses ADAM by default (via optimg); BFGS is available.
    • Objective can be chosen: objective = 'deff' (default) or objective = 'entropy' (cross-entropy/KL between expected next-wave respondent shares and population shares).
    • Optional “intercept shift” enforces next-wave expected respondents exactly by solving for a logit offset.
  • Not implemented or changed vs original code
    • No Stan/BridgeStan dependency; all objectives/gradients are native R.
    • No raking step in simulation summaries; results reflect post-stratification weights only.
    • No multi-outcome objective yet; current objective targets effective sample size via D_eff.
  • Planned additions
    • Optional weighted-estimator summaries alongside unweighted mean.
    • More robust convergence criteria and early-stopping diagnostics.
    • Cost-aware penalty/constraint (heterogeneous per-complete costs) in constrained objectives.

Dev helpers