[Stan 2.33] Pathfinder algorithm

[jgabry]

Expose Pathfinder: stan-dev/stan#3123 stan-dev/cmdstan#1155

Opening this so we have a CmdStanR issue, but main discussion is happening over in stan-dev/cmdstanpy#684

[jgabry]

@avehtari It would be good to get your thoughts on the proposed API over at stan-dev/cmdstanpy#684. There's also a slack discussion about how to handle the multiple arguments related to how many draws the user gets.

[jgabry]

@SteveBronder do you want to take a crack at updating your branch to match what @WardBrian did for CmdStanPy in stan-dev/cmdstanpy#686?

[SteveBronder]

Yeah sure!

[jgabry]

Cool, thanks!

[mitzimorris]

here's the current state of discussion w/r/t Pathfinder in CmdStanPy / CmdStanR

WIP for CmdStanPy:

stan-dev/cmdstanpy#686
stan-dev/cmdstanpy#684

conversation on Stan slack developers channel: https://mc-stan.slack.com/archives/C7V03NJHL/p1692985342918579

the two uses cases that most users care about are either:

• Pathfinder as approximate algorithm
• Pathfinder as initialization for sampler

the use case that only algorithm developers and Stan maintainers care about is getting outputs from single-path Pathfinder and single-path diagnostics on Pathfinder state at each ELBO evaluation.

w/r/t Pathfinder for approximation, the question on Stan slack is default size of PSIS sample and if that changes, how should the number of single-path Pathfinders and size of single-path samples be?

w/r/t Pathfinder for initialization, Pathfinder is intended to replace only phase 1 of Stan warmup; therefore, if using Pathfinder for initialization, we could adjust the settings for the warmup schedule. or not.

the good thing about the way the Stan handles the parameter inits file is that it doesn't care if there's extra crap in the varcontext object; so dumping all the Stan vars in a draw to JSON should be no problem - for R, there's discussion in another issue - #776 (comment)