6

Bug introduced in 10.0 or earlier and persisting through 12.1
The first symptom (histogram below) is gone in 12.0. The second (fraction of connected graphs) persists, showing that the sampling is still not uniform.

There are two undirected labelled simple graphs with the degree sequence {1, 2, 2, 1}:

enter image description here

RandomGraph[DegreeGraphDistribution[{1,2,2,1}]] will generate both, but not with exactly the same probability. The former seems to be generated slightly less often than the latter.

Here's proof:

ParallelTable[
  Table[RandomGraph@DegreeGraphDistribution[{1, 2, 2, 1}], {5000}] // 
      CountsBy[AdjacencyMatrix] // KeySort // Values // Apply[Divide],
  {500}
] // Histogram

enter image description here

The histogram you see above is for the ratio of the frequency of the first graph to the second (in samples of 5000).

Questions:

  • Is this expected or is it a bug? I am looking for an explanation of why the two graphs are not constructed with equal probability.
  • What method does RandomGraph[DegreeGraphDistribution[...]] use in M11.2?

Some methods would give approximate results, which is why documenting the method being used is important. A few years ago I asked Wolfram Support about the method, and I was told that it is based on the configuration model. I cannot see how this bias would arise with such a method.

Update 2019 March

Here's another, independent method to demonstrate that the sampling is not uniform. We are going to compute what fraction of the graphs with a given degree sequence are connected, and show that the estimate obtained with DegreeGraphDistribution is incorrect.

$Version
(* "11.3.0 for Mac OS X x86 (64-bit) (March 7, 2018)" *)

Create degree sequence:

ds = VertexDegree@KaryTree[9];

Approximate the fraction of connected graphs using RandomGraph[DegreeGraphDistribution[...]]. Multiple repetitions will give us an idea about the accuracy of the approximation.

Table[
 Mean@N@Boole[
    ConnectedGraphQ /@ 
     RandomGraph[DegreeGraphDistribution[ds], 100000]], {10}]
(* {0.43967, 0.44448, 0.44331, 0.44311, 0.44306, 0.4409, 0.44043, 0.44013, 0.44418, 0.44443} *)

Mean[%]
(* 0.44237 *)

Now we compute the exact result. This effectively generates all realizations of the degree sequence.

gs = 
  RandomGraph[DegreeGraphDistribution[ds], 100000] // 
   DeleteDuplicatesBy[AdjacencyMatrix];

Length[gs]
(* 1335 *)

(Yes, this is a hack, however I verified the result with an exact generation program that is too long to include here.)

The true fraction is approximately 0.472.

Mean@N@Boole[ConnectedGraphQ /@ gs]
(* 0.47191 *)

As you can see above, from DegreeGraphDistribution we consistently get 0.44, which is close, but clearly different.

For my work, I needed reliable estimates of this fraction for degree sequences which have many more realizations than what can be practically generated. Due to this failure, using DegreeGraphDistribution is not an option.

Szabolcs
  • 234,956
  • 30
  • 623
  • 1,263
  • It looks quiet even to me: In[43]:= Values[ CountsBy[RandomGraph[DegreeGraphDistribution[{1, 2, 2, 1}], {5000}], AdjacencyMatrix]]

    Out[43]= {2507, 2493}

     – halmir Mar 08 '18 at 15:33
  • @halmir What do you mean by "quiet"? I think it's a typo, and I can't quite figure out what you meant. Note that a KeySort is missing in front of the CountsBy in the input you showed—that's essential for comparing repeated runs. – Szabolcs Mar 08 '18 at 15:58
  • If you run Values@KeySort@CountsBy[RandomGraph[ DegreeGraphDistribution[{1, 2, 2, 1}], {20000}], AdjacencyMatrix] repeatedly, the first entry is almost always less than 10000 and the second is greater than 10000. – Szabolcs Mar 08 '18 at 15:58
  • 1
    All permutations of the given vertex degree list result in skewed histograms with {2,2,1,1} being the only exception. It turns out as one would expect for randomness, e.g. mode at 1.0. Should that not be invariant to order? – gwr Mar 08 '18 at 16:29
  • I have called this a "bug" now as at least there should be words of caution in the documentation imo. – gwr Mar 11 '18 at 12:00
  • 2
    @gwr There's also the issue that DegreeGraphDistribution is never explained in the documentation. We expect uniform sampling, but the documentation only says that it is a "degree graph distribution", which is not a standard term. In fact, if you use SelfLoops -> True, the sampling is no longer uniform for graphs with loops. That would be expected for the configuration model, but there's no mention in the documentation that that is what a "degree graph distribution" is supposed to mean. – Szabolcs Mar 15 '18 at 09:45
  • 1
    Furthermore, even if we don't set SelfLoops -> True, Mathematica will automatically create loops (and break uniform sampling) if the degree sequence is not realizable by a simple graph. – Szabolcs Mar 15 '18 at 09:46
  • 1
    @halmir Is it that DegreeGraphDistribution does not implement the configuration model with rejecting non-simple graphs in a direct way, but uses some trick to speed up things, and this trick introduces a small bias? If so, I'd be interested in what that trick is. I couldn't quite implement the configuration model in such a way that it's as fast as RandomGraph[DegreeGraphDistribution[...]] – Szabolcs May 02 '18 at 20:00
  • @halmir I included another example, which also illustrates how this is a problem for my work. I do have an independent implementation of the configuration model in IGraph/M. However, RandomGraph[DegreeGraphDistribution[...]] is faster. I would like to know how it works, and whether it can be fixed without slowing it down. – Szabolcs Mar 27 '19 at 14:03

0 Answers0