What can we add to the Stan model concept to help interface implementation?
- Prelim proposal for model base class
- expose more metadata about a model, like parameter constrained and unconstrained types and dimensionality
- subsets of parameters, keeping track of running means and running variances
Additional Stan services:
Unifying the interface API across packages (“Stan 3”)
- unifying names of parameters
- how are samples returned? (permuted? how? alignment across e.g. sampler params and samples)
- streaming output and analysis
- which doc can we share and how?
- model.sample vs sample(model)
- How to release? timing vs. Stan 3 language?
Interface package architecture
- arviz, HTTPStan, bayesplot. Best division of packages?
Lightweight cmdstan-based interfaces
- identify minimal set of features that need to be supported by an interface. Gives a target to new interfaces
- beta launch imminent
- long term plans
Stan language features
- general algorithm for community approval of feature or keyword selection
- ragged containers
- sparse matrices
- tuples / unions / structs / ?
- model composition (structs? submodels?)
- lambdas / closures / HOFs
- user-defined derivatives
Compare solutions for addressing compile times w.r.t. interfaces
- base model class
Define goalposts for algorithm inclusion
- level 1: stat_comp_benchmarks
- level 2: ???