Parameter Space Partitioning MCMC for Global Model Evaluation (Pitt, Kim, Navarro & Myung, 2006).

CRAN page of psp

To cite package ‘psp’ in publications use:

Lenard Dome and Andy Wills (2026). psp: Parameter Space Partitioning MCMC for Global Model Evaluation. R package version 1.0.6. https://CRAN.R-project.org/package=psp

A BibTeX entry for LaTeX users is

  @Manual{,
    title = {psp: Parameter Space Partitioning MCMC for Global Model Evaluation},
    author = {Lenard Dome and {Andy Wills}},
    year = {2026},
    note = {R package version 1.0.6},
    url = {https://CRAN.R-project.org/package=psp},
  }

Install

For the stable version

install.packages("psp")

For the developmental version:

# devtools::install_github("lenarddome/psp")
install.packages("psp", repos = c('https://lenarddome.r-universe.dev', 'https://cloud.r-project.org'))

About psp

• Package website, with reference and benchmarks
• A short intro and manual
• A brief blog post

Philosophy

A big influence on this implementation is an instantiation of the Open Models Initiative, catlearn. Watch the talk of Andy Wills: “The OpenModels project” from Open Research Working Group (ORWG) virtual meeting 08/09/20.

The project's architecture is also influenced by DEoptim. DEoptim implements a Differential Evolutionary Optimization algorithm formodel-fitting.

We are completely open-source and free. Anyone can contribute. If you would like to raise an issue or contribute code, use Github, message or email me (@lenarddome).

Code Style

We use Google’s R Style Guide with some extra caveats:

• Do not use roxygen. Write your documentation from scratch as an Rdocumentation file. It is desirable to avoid writing test units for converting your comments to documentation.
• We have a 100 characters per line policy. You are still encouraged to keep line lengths to 80 characters, but sometimes going over 80 can be better than the alternative.
• Use TODO, FIXME, HACK, BUG, WARNING, NOTE comments for code that is temporary, a short-term solution, or good-enough but not perfect.
  • TODO comments must adhere to the following format: ## TODO: change this to use matrix operations.
• Use spaces!
  • Good practice: if (makeup == TRUE) list(variable = runif(100), id = rep(letters, 5)[1:100]).
  • Bad practice: if(makeup==TRUE) list(variable=runif(100),id=rep(letters,5)[1:100]).
• Do not number your files. File naming conventions are pretty straightforward:
  • Files are prefixed by their relation to groups of functions. For example, the prefix psp means that the file contains function relevant for the parameter space partitioning routines.
  • Files use camelCase.
  • File names must not contain spaces.
• Apply the same conventions to C++ code as well. While we do not militantly adhere to this, study Google's C++ Style Guide.

Branch naming convention

A git branch should start with a category. Pick one of these: feature, bugfix, hotfix, or test.

• feature is for adding, refactoring or removing a feature
• bugfix is for fixing a bug
• hotfix is for changing code with a temporary solution and/or without following the usual process (usually because of an emergency)
• test is for experimenting outside of an issue/ticket

See this link for some great description of the naming convention.

Commit message conventions

Please follow the Conventional Commits guidelines for commit messages. Feel free to use gitmoji for commit messages, but insert them at the end of the problem description. See this link for more information.