Indexing: non-conformable arguments

203 views
Skip to first unread message

Lu

unread,
Jul 29, 2022, 3:17:17 AM7/29/22
to nimble-users
Hi everyone,

I am trying to build a longitudinal model in NIMBLE, but I encounter a question about the indexing, which generates an error called "non-conformable arguments" on matrix E. I tried to use some constant values for matrix E, and the model can be successfully built. However, with the indexing, it fails. 
The code is attached. Could you help me to figure this out?

Thank you for your attention, and any help would be much appreciated!

Best,
Zhihua
test.R

Perry de Valpine

unread,
Jul 29, 2022, 9:58:21 AM7/29/22
to Lu, nimble-users
Hi Zhu,
It looks like this error is coming from pure R (i.e. nimble uncompiled) calculation of your model.
It is happening when m[i] is 1.  In that case, (1+msum[i-1]):msum[i] is 1:1, or simply 1.  Then your quadratic form,
 E[(1+msum[i-1]):msum[i], 1:6] %*% Sigma[1:6, 1:6] %*% t(E[(1+msum[i-1]):msum[i], 1:6])
is not working correctly in R (or nimble).  Here is an example:
E <- 1:6 # E[(1+msum[i-1]):msum[i], 1:6] returns a vector of length 6, so it is something of the same type as 1:6
Sigma <- diag(6)
E %*% Sigma %*% t(E) # error

The problem is R dynamically evaluates the types of inputs to the %*% function.  When it sees a vector, it checks whether treating it as a one-row or one-column matrix will make it conformable. e.g. both of these work:
E %*% Sigma
Sigma %*% E
 But the default matrix for E is a one-column matrix, so t(E) is a one-row matrix, and this is non-conformable:  You are telling R which way you want it to handle E, and that way doesn't work.
Sigma %*% t(E)
Again, this error is occurring in R, but it is something you'll need to fix for nimble compilation to work as well.
There will also be an issue in nimble when you use extents like 1:m[i] that are simply 1:1.  So for both reasons, I'd suggest separating the cases where the extent is 1:1.  You could potentially pick those out separately and declare them in a for loop with scalar operations and a dnorm instead of dmnorm.

I also noticed nimbleModel is giving you a warning (at the end of its output) about multiple declarations of mu_tau.  If that is indexed only by t, it should not be in a loop with i.  You can make a separate loop over t to declare the mu_tau nodes.

I also noticed, in your R code for simulating inputs, the lines like
y[i,j] ~ rbinom(1, 1, 0.5)
are not doing anything.  In R code, you'll want "<-" instead of "~".

HTH and good luck with it.
Perry



--
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 on the web visit https://groups.google.com/d/msgid/nimble-users/fd33007c-70c1-4466-8332-f20f14a2035en%40googlegroups.com.

Lu

unread,
Jul 29, 2022, 9:47:23 PM7/29/22
to nimble-users
Hi Perry,

Thank you for your answer and suggestion. I have modify the code and now the model can successfully be built and compiled. Thank you for your help.
However, when I run "configureMCMC", errors show up as "Error in value[[3L]](cond) : node stack overflow
Error during wrapup: node stack overflow
Error: no more error handlers available (recursive errors?); invoking 'abort' restart"
I don't know why this happens. Could you help me figure this out? The new version of my code is attached. Thank you so much! 
Best,
Zhihua

test_v2.R

Daniel Turek

unread,
Aug 1, 2022, 11:55:14 AM8/1/22
to Lu, nimble-users
Zhihua, thanks for your email and your patience.

I took a quick look, and this is a subtle case indeed, with the dependency paths of your deterministic nodes in combination with the matrix multiplications, this enters into an obscure part of the conjugacy checking, which here gives an infinite recursion - the check repeatedly creats its own internal "structure expression" object to represent your calculations, then re-processes it over, and over, again.  Sorry, this bug is my fault.

I'll be working on a patch for our next release.  In the meantime, you can work around it easily by disabling the conjugacy checking:

longconf <- configureMCMC(longpro, print = TRUE, useConjugacy = TRUE)

Let us know if this works for you.  And like I said, we'll get this fixed in a future release.

Cheers,
Daniel




Lu

unread,
Aug 1, 2022, 8:45:03 PM8/1/22
to nimble-users
Hi Daniel, 

Thank you for your suggestion. Indeed, it works for me by using:  
       longconf <- configureMCMC(longpro, print = TRUE, useConjugacy = FALSE)
Thank you so much for your help!!!!!


Best,
Zhihua
Reply all
Reply to author
Forward
0 new messages