"bad parameters" for Conway Maxwell Poisson distribution

[SimonGE]

I am trying to implement a model of highly consistent (under-dispersed) counts in NIMBLE. 

The model has two likelihood components defined by custom distributions: 1) a beta-binomial and 2) a Conway Maxwell Poisson. I have tried writing these custom distributions based others' code here, here, and here but after what looks like success with the beta binomial component, I am getting the error:

`bad parameters for distribution dcomp(lambda = lam_ci, nu = theta_c).`

This seems to originate in misnamed arguments or incorrect type declarations but I can't see where I'm going wrong. I am a novice with these custom distributions so please excuse an obvious mistake.

I'll note that in one of the links, another user took advantage of `nimbleRcall()` and ran the model using pre-existing code. Although this worked in my case also, I would like to avoid loading other packages that have this distribution and random sampler so that the script can stand alone as much as possible. I also wondered if nimbleRcall was contributing to slowing down the MCMC compared with the 'built-in' Poisson. Is that a reasonable speculation?

Thank you,

[Chris Paciorek]

Hi Simon,

I think you need to provide the value of `sumTo` when you use `dcomp` in your model. We allow use of default arguments in nimbleFunctions generally, but for distributions, we need to match argument names to parameters in such a way that I don't think we support a case of not passing in an argument (apart from `log`, which is set to TRUE automatically).

-chris

--
You received this message because you are subscribed to the Google Groups "nimble-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to nimble-users...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/nimble-users/06cb7b8c-f3f0-4038-92b6-48de29819f01n%40googlegroups.com.

[Perry de Valpine]

And to your question about nimbleRcall: yes this will definitely slow things down. It has to hand processing back to the R interpreter (i.e. to R).

To view this discussion visit https://groups.google.com/d/msgid/nimble-users/CA%2B7Ts_pa7c%3Dt7Lwo8q3dA55Dd8o4WNGfgifdXad%2BFnNoU0pPdQ%40mail.gmail.com.

[SimonGE]

Hi Perry and Chris,

Thanks for your responses. Chris, I've hard-coded the normalizing constant in the nimble function and that did indeed solve the "bad parameters" problem.

Perry, this is a relief. The model runs much more slowly after adding the dcmp via nimbleRcall compared to the built-in dpois so I'm glad to know there's still hope once the nimble function is running.

I've re-coded the d and r functions but have encountered this other error before the MCMC starts sampling (i.e. as the model is compiling):

Error in rle(isScalar) : 'x' must be a vector of an atomic type

I've checked the return types and and it all appears fine to me. I am suspecting the issue is actually with the random number function because the model compiles and runs fine when I use the nimbleFunction distribution function and use nimbleRcall for the random number sampler.

Any suggestions about where I am going wrong would be greatly appreciated!

[Perry de Valpine]

Hi Simon,

I ran your code and used to following to track down where the error occurs

m <- nimbleModel(model, inits = init, data = data, constants = cons)
options(error=recover)
cm <- compileNimble(m)

Please replace 

dist <- c() 

with

dist <- numeric(length=500)

and

sample <- c()

with

sample <- 0

c() isn't a valid way to initiate a variable in nimbleFunction programming, although it's not error-trapped very well.

With those changes, your model compiles for me. Let's hope those are the only problems.

Perry

To view this discussion visit https://groups.google.com/d/msgid/nimble-users/9d77da4c-5705-4edf-869c-0c2d28fa76a4n%40googlegroups.com.

[SimonGE]

Terrific! And thanks for the timely response, Perry.

Yes, I didn't pick that up in the manual -- sorry if I missed it. That fixed it and now the model runs much more quickly than with the nimbleRcall.

Best,

Simon