I don’t think this can be removed unless RStan and CmdStan always support the same syntax. If there are discrepancies in the syntax available (e.g. RStan lagging behind due to CRAN) then we need both, right? Or am I misunderstanding?
please look at the code chunks in Cmdstanr code chunk in Quarto not displaying correct color coding - #5 by karimn and explain why one chunk should be tagged cmdstan as both code chunks are Stan language snippets.
the problem here is that the vignette is unclear. perhaps the OP is misconstruing how it should be used. this is not their fault - I don’t understand this feature either and I think the label cmdstan is just wrong. CmdStan is the command-line interface, not Stan statements, not R, Python, etc.
These code chunks are not just for display, they actually execute and create a new variable which stores a RStan StanModel or CmdStanModel built from the code in the block.
2 Likes
I agree that logically it doesn’t make sense to have both stan and cmdstan chunks, but that’s one way to allow users to choose between cmdstanr and rstan. The other way, using cmdstanr::register_knitr_engine doesn’t work.
It seems like the whole session should just use the same engine and perhaps allow users to use both engines (if needed for some reason) by using chunk options rather than chunk tags.
Also, stan chunks should really be able to support Quarto style options such as
```{stan}
\\ label: my-model
\\ output-var: my_model
\\ cache: true
\\ engine: cmdstanr
…
```
1 Like
thanks for the clarification.
@jonah - if CmdStanR is going to support this, the tag should be cmdstanr, and you might consider supporting all the compiler options as well.
Definitely open to suggestions for improving this. This feature was contributed by @bearloga who knows a lot more about knitr/r-markdown than I do, but if they’re not available to take a look I can maybe figure it out or ask someone else.
If anyone has suggestions for how to implement something or is interested in helping to work on this, here’s another link to the issue that @mitzimorris opened on GitHub:
Thanks for reporting the problem.
perhaps quarto integration with RStudio doesn’t use knitr?
I think that adding more chunk options to tag stan for R users who want to use the compilation feature might work - suggestions in github issue.
2 Likes
The cmdstanr::register_knitr_engine approach works for me in Quarto and VSCode. Haven’t tried RStudio (can’t run it on my machine). Here’s what I did:
- Include
cmdstanr::register_knitr_engine(override = TRUE)in an R code chunk. - Write my Stan code in a Stan code chunk.
- Specify
#| output.var = "model-name"at the top of the Stan code chunk. - Run the model using cmdstanr in an R code chunk by calling
model-name$sample().
For me this results in proper syntax highlighting in the Stan model code chunk, as well as sampling via cmdstan.
Here’s a reproducible example that works on my computer:
Setup in an R code chunk:
cmdstanr::register_knitr_engine(override = TRUE)
options(mc.cores = parallel::detectCores())
Declare the Stan model in a Stan code chunk. We can use the output.var parameter to save it as a cmdstanr object in the R environment:
#| output.var = "fake-model"
data {
int<lower=1> n;
vector[n] y;
}
parameters {
// 確率的レベル
vector[n] mu;
// レベル撹乱項
real<lower=0> sigma_level;
// 観測撹乱項
real<lower=0> sigma_irreg;
}
transformed parameters {
vector[n] yhat;
yhat = mu;
}
model {
for(t in 2:n)
mu[t] ~ normal(mu[t-1], sigma_level);
y ~ normal(yhat, sigma_irreg);
}
Run the model in an R code chunk:
# Prepare the data list for the Stan model
data_list <- list(
y = rnorm(100, 0, 1),
n = 100
)
# Fit the model
fit <- `fake-model`$sample(
data = data_list,
iter_warmup = 1000,
iter_sampling = 1000
)
# Save the model
fit$save_object(file = "fake-model")
---
1 Like
