Inconsistent behaviour in network.list() with simulate(..., simplify = FALSE), paticularly for print() methods.

[krivit]

library(ergm)
data(faux.desert.high)
s <- simulate(faux.desert.high ~ mm("sex"), coef = c(-3.486, -3.278, -3.361), nsim = 2, simplify = FALSE)
str(s)
#> List of 1
#>  $ :List of 2
#>   .. .. .. .. [networks]
#>   .. .. .. .. [list output truncated]
#>   .. .. ..- attr(*, "class")= chr "network"
#>  - attr(*, "constraints")=List of 2
#>   ..$ :Class 'formula'  language ~.
#>   .. .. ..- attr(*, ".Environment")=<environment: 0x55fadfc0d000> 
#>   ..$ :Class 'formula'  language ~.
#>   .. .. ..- attr(*, ".Environment")=<environment: 0x55fadfc0d000> 
#>  - attr(*, "reference")=Class 'formula'  language ~Bernoulli
#>   .. ..- attr(*, ".Environment")=<environment: 0x55fadfc0d000>
print(s)
#> Number of Networks: 1 
#> Model: faux.desert.high ~ mm("sex") 
#> Reference: ~Bernoulli 
#> Constraints: ~. ~.

Created on 2025-05-28 with reprex v2.1.1

The problem is that the underlying code always returns a list of lists: a list of parallel runs with each element being a list of resulting networks. When not running in parallel, the top-level list has length 1, and the network statistics are returned in an mcmc.list object.

When simplify = TRUE (the default), simulate() flattens this list and converts the mcmc.list into a matrix. If not, it returns them as they are.

The most immediate consequence of this is that it messes up the print() and summary() methods, since they rely on the length() of the object for the number of networks. This is easy to fix.

More generally, the resulting object isn't technically a list of networks anymore, but a list of lists of networks, so there is an argument to be made for creating a network.list.list class that contains network.list objects, one for each parallel run.

[krivit]

This also raises the question of what the c.network.list() function (#603) should do if given unsimplified simulation outputs.

[mbojan]

Hmm, maybe we can get some inspiration from MCMC-related packages like coda for handling results with multiple chains that were sampled in parallel. I can imagine that it might be something you do not want immediately ignore or discard and investigate between-chain differences and so on. On the other hand, I'd hate to over-complicate this whole thing.

[krivit]

You can now test for unsimplified list by seeing if it inherits from network.list.list. Suppose that there is c1 chains of n1 networks and c2 chains of n2 networks. Then, I think there are two plausible behaviours:

1. Concatenate "wide", as if you has c1 + c2 parallel chains. This only works if n1 == n2.
2. Concatenate "long", as if your sample size had been n1 + n2. This only works if c1 == c2.

[krivit]

@mbojan , {ergm} 4.9 needs to go as soon as possible. Do you think you might be able to sort this out in the next day or two? Thanks!

[mbojan]

No, I didn't, but should be able to look into it within 1-2 days counting from tomorrow. Sorry!

[krivit]

I think this is going to have to go into the next release.