User friendly description of tergm algorithm

[martinamorris]

From #120 (comment)

Each TERGM step requires (in principle) an independent draw from an ERGM. The problem is that how many proposals that takes depends on network size, model complexity, and other factors.

The idea of the algorithm is that at the start of the time step, the current network will be identical to the initial network, and as MCMC sampling proceeds, it will diverge more and more. Thus, there will be a trend in the Hamming distance between them, or, equivalently a prevalence of +1 increments in it after each MCMC step over the -1 increments.

Then, once it reaches an equilibrium, there should be about as many +1s as -1s. Also, while the increments are not, strictly speaking, uncorrelated (as they are negatively so), they are pretty close to uncorrelated, particularly for larger networks.

The algorithm then keeps track of the weighted average of these increments, exponentially weighed by how long ago they happened, as well as of its variance, which it then uses to set up a statistic. Once it can no longer detect a trend (with a very high alpha) using a one-sample z-test for mean, it concludes that the sequence has converged.

To consider:

• New vignette, with above text and single operator models examples
• Add text above to tergm workshop appendix
• Review current tergm vignettes https://github.com/statnet/tergm/tree/master/vignettes for updating/deletion

[krivit]

I am not sure. This is a deep technical detail that just works, and I am not sure end-users will benefit from knowing about it. I won't stop you, but I am not sure it's worth the effort.

[martinamorris]

As someone who comes at all this work from a less technical background, I remember finding it incredibly helpful when we were first trying to figure out why stergms were taking so long to estimate. Nicole wrote up a summary of her findings, and it helped me understand, for the first time, both the raw mechanics of the MCMC estimation in this context, and the opportunities for tweaking the algorithm to be more efficient/faster.

And given that a user (albeit a tech savvy one) asked this question, it does seem like I'm not the only one who would benefit.

In any case, the ratio of code to user-friendly documentation for all the statnet packages is a bit top-heavy. This seems like a low-cost contribution to fixing that. Esp. since you've already written it down ;)