Dissolution vs. Persistence: Is now the time to fix this?

[martinamorris]

Our "dissolution" coefficients in tergm actually represent the conditional log odds of persistence, not dissolution.

While the translation into a dissolution coefficient is easy (just take the negative), the discrepancy between our terminology and the true effect is not optimal. It's likely to cause problems for the naïve user, and possibly even lead to errors in published work. We spend an inordinate amount of time in the tergm tutorial repeating that "dissolution" really means "persistence".

Now that the 4.0 packages are about to be released, I'd like to suggest we fix this.

@krivit has identified the 2 options:

1. Change all of our terminology to "persistence", and banish the word "dissolution" from our world.
2. Flip the signs of the coefficients so they represent dissolution.

Option 1 puts us beyond the pale in terminology. Everyone uses formation and dissolution.

Option 2 is not backwards compatible.

Doing nothing is just as bad.

Discuss
@statnet/dev @statnet/commons

[CarterButts]

Yes, this is indeed something that really confuses folks: "persistence" is both accurate and more mechanistically intuitive (i.e., it leads us to think of reasons that a tie might be sustained, rather than e.g. factors that would actively break an edge). In the abstract, I really like the idea of moving to persistence But I am very negative about changing conventions and breaking things, so there's that.

What about:

1. Adding "persistence" as a synonymous argument to "dissolution" in all (s)tergm tools for which it is relevant;
2. Gradually migrating to "persistence" in tutorials and such, with a note that this was historically called "dissolution" but that we are trying to shift usage to be more accurate about what the terms do;
3. Eventually, if folks seem to have moved to the new usage, deprecating "dissolution."

This would seem to be pretty low cost from a code/maintenance standpoint, is backward compatible, and generally does no harm. But it also gives us room to break out of our cycle of dissolution. A viable compromise, perhaps?

[sgoodreau]

Of the three bad options (including doing nothing), I also favor a switch to persistence. And I like Carter's approach of trying to make it as unpainful as possible.

It sounds like you're talking about this for the imminent statnet 4.0 release, but doing this well mean coordinating with EpiModel, no?

[chad-klumb]

I don't think this should be rushed into the current release.

[martinamorris]

I have a pretty strong preference for using the most common terminology: formation and dissolution. This is how most people think about tie dynamics. The fact that the coding flipped this, because it was easier/more convenient to represent the statistics in terms of persistence, is not, by itself, a good reason to make everyone change how they think about tie dynamics. That's a bit like the tail wagging the dog.

Given all the other complications in these methods that we are asking people to learn, this seems like one place where we could avoid making things more difficult. IIUC, it would require flipping the sign of the coef -- which is a smaller change that updating all of our written materials to say "persistence". And I'm pretty sure we would all find ourselves still using the term dissolution in practice. It's just the norm.

I like Carter's idea of implementing both. The "persistence" term can be implemented with a Persistent() operator, and the existing Diss() operator will just flip the signs of the coefs, so that the direction aligns with the terminology. I'm not sure we need to consider deprecating either one, unless we find having both causes other problems.

[krivit]

Sounds like we have a consensus for a Persist() operator, so that should definitely go in.

The point of contention seems to be whether we should deprecate/remove Diss() or to keep it but negate the signs of the statistics.

I like the idea of having Diss() do that eventually, but as long as we are supporting the legacy stergm() syntax, it would be problematic if the dissolve= formula had the opposite parameter interpretation from the formula in the Diss() operator.

The option that I increasingly prefer is a clean break. We are not "deprecating" the Diss() operator, because there never was one, except in a development version that never made it to CRAN. We are free to just not provide a Diss() operator. Then, some time after we deprecate and remove old-style stergm(), we can introduce the Diss() as a convenience operator that is just Persist() with negated statistics.

It would require going through all files in tergm that mention dissolution and rewording where needed, but the alternatives (introducing a term that we don't want people to actually use or introducing Diss() which means the opposite of dissolve=) seem even worse.

[CarterButts]

The fact that the coding flipped this, because it was easier/more convenient to represent the statistics in terms of persistence, is not, by itself, a good reason to make everyone change how they think about tie dynamics. That's a bit like the tail wagging the dog.

Except that I do think that it's often more natural to think about dynamics in most social settings in terms of persistence rather than dissolution. :-) So I'm not sure it's entirely a tail-wagging-dog situation.

But that said, there is clearly merit in being able to look at it either way. In some settings - say, Facebook friendships - ties automatically persist until someone actively breaks them. In that case, dissolution makes much more sense than persistence, because you want to parameterize the forces that would actively disrupt the tie (i.e., motivate someone to take action to break it). By turns, something like an advice-seeking relationship takes constant action to maintain, and it makes more sense to parameterize that in terms of persistence (since you are usually interested in parameterizing the forces that would tend to keep the interaction from dissipating). In yet other cases, the two approaches might be equally direct.

So I would buy the argument for just retaining the ability to look at the model from either angle. It's like the "Heisenberg picture" versus the Schrodinger picture" in matrix mechanics: the two are equivalent (they are related by a change of basis), but each is a lot easier to work with in specific settings. And indeed there is a third "picture" in a STERGM, which is the "TERGM picture" of the STERGM in which all of this is written in terms of the probability that an edge will be observed (full stop). (A STERGM is after all just a TERGM with a particular choice of dependence/homogeneity assumptions and some interactions involving the lagged network. It's a very specific set of assumptions, of course, but the "full TERGM" view of the STERGM is equally valid.)

[handcock]

To the degree that I have a say here, and also that any solution is a different irritant, I like the solution with Persist and also Diss() or Dissolve as a convenience operator that is just Persist() with negated statistics. The documentation can focus on one (i.e., Diss(). Version 4 is enough of a jump to justify the negation.

[martinamorris]

Surprisingly, I think we have consensus on having 2 operators. (it's not easy to get consensus in this group ;)

Pavel, since we've got the package release candidates queued up for release this week, how do you want to handle this? Release with the Persist() operator, and add the Diss() operator later? Or release both now. Either way, it will require a fairly thorough check of all of the vignettes and helpfiles for the word "dissolution" to make sure terminology is aligned with syntax.

[krivit]

OK, if we go ahead and do both,

• Persist() operator itself is easy, since it's just a search and replace.
• The new Diss() for CMLE could probably be implemented using the Sum() operator to negate the statistics.
• The new Diss() for EGMME by adding a flag to the current implementation of Diss() to negate all statistics.

I can do that quickly. However, we also need to:

• Update other references to Diss(), including the EDApprox code and stergm() compatibility code. In some cases, Diss() should be replaced with Persist() and that's it; In others, both need to be handled. I think @chad-klumb knows this code the best at the moment.
• Update documentation, examples, vignettes, and tests throughout. My sense is that this isn't just a global search-and-replace, but, on the other hand, anyone present can work on this efficiently.

I've created a branch diss-persist for doing this work. Note that the last item (documentation) would need to be done whether or not we add a Diss() operator or just rename Diss() to Persist().

Addendum: When working on the last two items, please don't wait for me to implement the first three. I will be working on that in parallel, and you can assume that these changes will be made. That said, to avoid wasting time, could we please confirm that:

• @chad-klumb can work on the fourth item, and
• we know precisely who will be working on the last item

before I start?

[chad-klumb]

Is the intent to also define a suitable summary version of Diss so that e.g. summary(nw ~ Diss(~edges)) returns the number of edges dissolved on the last time step (rather than minus the number of edges persisting across that time step)?

[martinamorris]

I would hope that would be the behavior.

[chad-klumb]

I don't know what the fourth item is asking me to do.

[krivit]

I am not sure I understand the question. Diss should all be in persistence, but with a minus sign. (I'll try to push an initial implementation tonight.)

[chad-klumb]

~-edges-triangle or ~Sum(-1~edges + triangle, label = c("edges", "triangle"))?

[krivit]

The latter.

[martinamorris]

it should produce what it produced in the previous version of tergm, right?

[krivit]

@chad-klumb , by the way, I've made some tweaks to the Sum() operator, which will hopefully make using it to negate and otherwise scale easier. I've also made the handling of durational terms inside operators a bit more robust (i.e., operators now check if they can safely handle one).

Once I push the changes, it should be possible to basically implement Diss(X) = Sum(-1~Persist(X), label=I), at least for now.

[martinamorris]

I'll work on the documentation -- outside of the tergm package and the workshop (which is still under construction anyway).

Here are some examples of files with the word "dissolution" in the repo:

• Most are .Rd files, I'll edit the corresponding .R file that produces them where appropriate
  • Quite a few items are stergm specific. I'm thinking we don't want to change those. Old stergm will still use the syntax formation= and dissolution=, right? And we don't have plans for that to change. If so, I'll just make sure the docs are clear that in this old syntax dissolution produces an equation for persistence.
• I'm going to ignore the STERGM vignette as well

Of the .Rd files:

I think that ergm-terms.Rd will require the most effort, as it covers all the ground. Will probably have some questions...

[krivit]

Thanks, @martinamorris. For old stergm, we need to make it absolutely clear in the docs that old dissolution not the same as the new Diss().

[martinamorris]

adding this:

#' Note:  The old \code{dissolution} formula in \code{stergm} represents
#' tie persistence.  As a result it maps to the new \code{Persist()} operator
#' in \code{tergm}, NOT the \code{Diss()} operator

eventually (soon!) i think we want to deprecate stergm.

[krivit]

The implementation, as originally described, is there. I've also added some (but probably not enough) tests. How is the rest of the implementation and documentation coming? @chad-klumb , by the way, in case it helps, the EGMME Diss() operator now behaves just like the others: it has its own C implementation.

[krivit]

It seems to pass all checks. Are we good to merge? @martinamorris , @chad-klumb ?

[chad-klumb]

I am not aware of a reason why it shouldn't be merged.

[krivit]

Now merged into master. Any further fixes should go there.