inconsistent use of row- vs. column-major ordering of node names

[paciorek]

I'm surprised this hasn't come up (perhaps it has).

getDependencies and getNodeNames use row-major ordering while expandNodeNames uses column-major.

code <- nimbleCode({
  for(i in 1:2)
    for(j in 1:3)
      y[i,j]~dnorm(mu,1)
  mu ~ dnorm(0,1)
})

m <- nimbleModel(code)
m$getNodeNames()
m$expandNodeNames('y')
m$getDependencies('mu')

[1] "mu"      "y[1, 1]" "y[1, 2]" "y[1, 3]" "y[2, 1]" "y[2, 2]" "y[2, 3]"
[1] "y[1, 1]" "y[2, 1]" "y[1, 2]" "y[2, 2]" "y[1, 3]" "y[2, 3]"
[1] "mu"      "y[1, 1]" "y[1, 2]" "y[1, 3]" "y[2, 1]" "y[2, 2]" "y[2, 3]"

Given nimble 2.0, I think this is mainly a curiosity at this point.

[paciorek]

Actually to confuse things, if we reverse i and j, we get consistent column-major ordering:

code <- nimbleCode({
  for(i in 1:2)
    for(j in 1:3)
      y[j,i]~dnorm(mu,1)
  mu ~ dnorm(0,1)
})

m <- nimbleModel(code)
m$getNodeNames()
m$expandNodeNames('y')
m$getDependencies('mu')

[1] "mu"      "y[1, 1]" "y[2, 1]" "y[3, 1]" "y[1, 2]" "y[2, 2]" "y[3, 2]"
[1] "y[1, 1]" "y[2, 1]" "y[3, 1]" "y[1, 2]" "y[2, 2]" "y[3, 2]"
[1] "mu"      "y[1, 1]" "y[2, 1]" "y[3, 1]" "y[1, 2]" "y[2, 2]" "y[3, 2]"

[perrydv]

I think this is understood behavior and there are reasons not to expect universal agreement in ordering.

getDependencies and getNodeNames are inherently (topologically) sorting. expandNodeNames is not.

For nodes that are really topologically tied, their sort order comes from the order of declaration, which explains your second comment. (There are no actual ties in nimble's DAG representation.)

getDependencies gives sorted results by its very nature. That is part of its point.

getNodeNames gives sorted results based on how it works. The user requests a category like topOnly, which is obtained by matching to the type list, which comes from a set of vectors of node information that are set up in topological order. So de facto getNodeNames will give a result in sorted order.

expandNodeNames gives the consistent behavior of column-major ordering, which is natural when one is thinking about variables in contexts where topological order is not an issue. For example, it seems to have worked well to return MCMC output columns in this order. The nodes within a variable could potentially have arbitrary topological ordering, and then returning MCMC output in that ordering could be confusing. Similarly making values(model, nodes) use topologically sorted ordering could be confusing. Both of these cases use expandNodeNames ordering. It works well that this ordering is consistent, e.g. so a set of columns from MCMC output can be assigned into a model using values()<- (when iterating over a sample for some kind of posterior summaries or predictions) and the ordering of both is straightforward and consistent.

I think for these reasons, we realized back when we made these features that always going through a sorting step was not necessarily desirable. Hence I don't think there is an issue here.