nimble-dev / nimble

The base NIMBLE package for R
http://R-nimble.org
BSD 3-Clause "New" or "Revised" License
158 stars 24 forks source link

mcmc dimnames with samplesAsCodaMCMC=TRUE have empty space #1088

Open Schmidtpk opened 3 years ago

Schmidtpk commented 3 years ago

Compared to standard JAGS implementations the mcmc object generated by nimble with the option samplesAsCodaMCMC=TRUE has empty spaces after the comma in dimnames.

varname[1, 1]

instead of

varname[1,1]

This can break code used for JAGS before, for example when relying on the tidybayes package. A change to the way rjags saves the dimnames might be worth considering.

danielturek commented 3 years ago

@Schmidtpk Thanks for the suggestion. We will look into this.

perrydv commented 3 years ago

@Schmidtpk @danielturek I note that the version with the space corresponds to node names in nimble, and also to the R parse and deparse system (the reason for nimble's syntax for node names): deparse(parse(text = "varname[1,1]")[[1]]) returns "varname[1, 1]" Maybe a utility function (rather than an option) to rename as JAGS would be helpful?

paciorek commented 3 years ago

I see @perrydv 's point, but at the same time if we are not playing well with packages that do downstream processing, we're not being very user-friendly.

I'd like to better understand what form of input tidybayes and other downstream processors take - would it always be a CODA-based object? @Schmidtpk do you know?

If so, there may be an argument for having an argument to runMCMC and nimbleMCMC or a nimble option that does the gsub on the colnames of the mcmc object (or mcmc.list elements) to remove spaces. Of course we could simply provide a utility function, roughly:


strip_coda_var_names <- function(x) {
if(is.mcmc.list(x)) 
   x <- lapply(x, strip_coda_var_names)
if(is.mcmc(x))
   colnames(x) <- gsub(" ", "", colnames(x))
return(x)
}  
Schmidtpk commented 3 years ago

I'd like to better understand what form of input tidybayes and other downstream processors take - would it always be a CODA-based object? @Schmidtpk do you know?

I can't offer a broader picture, sadly. It was my perception that output types are somewhat fragmented, and downstream packages allow different subset of input types; with coda's mcmc and mcmc.list beeing the most common.