I asked a question regarding negative values of null dyads in dyad census I had previously and thanks to Szhorvat for answering it. It was very helpful. I have a follow-up question I would appreciate any insights if possible. Research in multigraph recognizes social network data often comprise multiple edges and loops in their natural state and simplifying by collapsing edges and removing loops discards information inherent to the network. I’m just wondering if dyad census in igraph would consider offering a way to take into account multiple edges and loops in the analysis? Or is this question irrelevant to dyad census? I hope it’s not weird to think negative values of null dyad is making sense as long as the sum of MAN still comes to 10, the total number of isomorphism classes. And the pattern I had did reflect actors’ behavior well. I cannot find any research about multiple edges in dyad census and would appreciate any reference to any. Thanks so much.

“Dyad census” simply means counting how many pairs of vertices have:

o o, no connection

o --> o, a unidirectional connection

o <-> o, a bidirectional connection

Since dyad census just means counting different types of vertex pairs, negative values obviously make no sense. As I said in the other thread, the negative value is a result of integer overflow, i.e. a computational limitation. This will be partially addressed when R/igraph is updated to use version 0.10 of C/igraph (i.e. likely in igraph 2.0).

Whenever a negative value appears, there should be a warning message, as below:

If you don’t see a warning, please show a complete minimal example that reproduces the issue, so we can track down and correct the problem.

The classic “dyad census” is plain counting of vertex pairs, so self-loops and multi-edges are ignored. There are possible generalizations of the idea, but those would be a different concept.

You may want to look into the literature on weighted motifs (not implemented in igraph at the moment).

Edge multiplicities can be regarded as edge weights. Based on these, one may assign a weight to each subgraph that’s being considered, and instead of counting subgraphs directly, we can add up their weights.