internlm/SWE-Fixer-Train-110K huggingface dataset:
Repository: networkx/networkx

Issue:
Heads up: Latest documentation now uses dark mode by default depending on browser defaults
With `pydata-sphinx-theme==0.9`, the documentation now defaults to light/dark mode depending on your browser preferences. Mine happen to be set to dark, so I see the following at https://networkx.org/documenation/latest

![Screenshot_20220609_083711](https://user-images.githubusercontent.com/1268991/172772573-a00da108-528f-415e-94de-8a9aef4a7f57.png)

IMO the dark mode is still a little rough around the edges - the logo and banner don't look great and the dark background is a deeper black than the default darkmode for other sites.

I think we should do a little experimentation with dark mode for the site before releasing it to users. I'd propose to configure the theme to force light mode (i.e. the behavior up until v0.9) until we've had a chance to play around with dark mode a bit more.


Discussion:

Resolving patch:
diff --git a/doc/conf.py b/doc/conf.py
--- a/doc/conf.py
+++ b/doc/conf.py
@@ -135,7 +135,7 @@
         },
     ],
     "external_links": [{"name": "Guides", "url": "https://networkx.org/nx-guides/"}],
-    "navbar_end": ["navbar-icon-links", "version"],
+    "navbar_end": ["theme-switcher", "navbar-icon-links", "version"],
     "page_sidebar_items": ["search-field", "page-toc", "edit-this-page"],
 }
 html_sidebars = {
@@ -188,6 +188,7 @@
         "latest": "devel (latest)",
         "stable": "current (stable)",
     },
+    "default_mode": "light",
 }
 
 # Options for LaTeX output
diff --git a/networkx/algorithms/distance_measures.py b/networkx/algorithms/distance_measures.py
--- a/networkx/algorithms/distance_measures.py
+++ b/networkx/algorithms/distance_measures.py
@@ -52,7 +52,9 @@ def extrema_bounding(G, compute="diameter"):
     NetworkXError
         If the graph consists of multiple components
     ValueError
-        If `compute` is not one of "diameter", "radius", "periphery", "center", or "eccentricities".
+        If `compute` is not one of "diameter", "radius", "periphery", "center",
+        or "eccentricities".
+
     Notes
     -----
     This algorithm was proposed in the following papers:


Test patch:
Repository: networkx/networkx

Issue:
 Improve test coverage for algorithms in load centrality
<!-- If you have a general question about NetworkX, please use the discussions tab to create a new discussion -->

<!--- Provide a general summary of the issue in the Title above -->

Currently we don't have full coverage for the algorithms in load centrality. Code blocks which are highlighted with red at codcov https://app.codecov.io/gh/networkx/networkx/blob/main/networkx/algorithms/centrality/load.py don't have corresponding tests. The tests should be added in https://github.com/networkx/networkx/blob/main/networkx/algorithms/centrality/tests/test_load_centrality.py

### Current Behavior

<!--- Tell us what happens instead of the expected behavior -->

We don't test all the paths the code can take us.

### Expected Behavior

<!--- Tell us what should happen -->

We should be testing everything so there aren't any surprises.

### Steps to Reproduce

<!--- Provide a minimal example that reproduces the bug -->

Visit https://app.codecov.io/gh/networkx/networkx/blob/main/networkx/algorithms/centrality/load.py



Discussion:

Resolving patch:
diff --git a/networkx/readwrite/adjlist.py b/networkx/readwrite/adjlist.py
--- a/networkx/readwrite/adjlist.py
+++ b/networkx/readwrite/adjlist.py
@@ -60,6 +60,14 @@ def generate_adjlist(G, delimiter=" "):
     --------
     write_adjlist, read_adjlist
 
+    Notes
+    -----
+    The default `delimiter=" "` will result in unexpected results if node names contain
+    whitespace characters. To avoid this problem, specify an alternate delimiter when spaces are
+    valid in node names.
+
+    NB: This option is not available for data that isn't user-generated.
+
     """
     directed = G.is_directed()
     seen = set()
@@ -113,6 +121,11 @@ def write_adjlist(G, path, comments="#", delimiter=" ", encoding="utf-8"):
 
     Notes
     -----
+    The default `delimiter=" "` will result in unexpected results if node names contain
+    whitespace characters. To avoid this problem, specify an alternate delimiter when spaces are
+    valid in node names.
+    NB: This option is not available for data that isn't user-generated.
+
     This format does not store graph, node, or edge data.
 
     See Also


Test patch:
Repository: networkx/networkx

Issue:
In smallworld.py: ZeroDivisionError when passing a graph without edges
This is a similar error to #6144 that comes from the use of `nx.utils.cumulative_distribution` with graphs without edges. In #6144 there is a deeper explanation of the bug. 



Discussion:

Resolving patch:
diff --git a/networkx/algorithms/smallworld.py b/networkx/algorithms/smallworld.py
--- a/networkx/algorithms/smallworld.py
+++ b/networkx/algorithms/smallworld.py
@@ -46,6 +46,11 @@ def random_reference(G, niter=1, connectivity=True, seed=None):
     G : graph
         The randomized graph.
 
+    Raises
+    ------
+    NetworkXError
+        If there are fewer than 4 nodes or 2 edges in `G`
+
     Notes
     -----
     The implementation is adapted from the algorithm by Maslov and Sneppen
@@ -58,7 +63,9 @@ def random_reference(G, niter=1, connectivity=True, seed=None):
            Science 296.5569 (2002): 910-913.
     """
     if len(G) < 4:
-        raise nx.NetworkXError("Graph has less than four nodes.")
+        raise nx.NetworkXError("Graph has fewer than four nodes.")
+    if len(G.edges) < 2:
+        raise nx.NetworkXError("Graph has fewer that 2 edges")
 
     from networkx.utils import cumulative_distribution, discrete_sequence
 
@@ -119,7 +126,7 @@ def lattice_reference(G, niter=5, D=None, connectivity=True, seed=None):
     Parameters
     ----------
     G : graph
-        An undirected graph with 4 or more nodes.
+        An undirected graph.
 
     niter : integer (optional, default=1)
         An edge is rewired approximatively niter times.
@@ -139,6 +146,11 @@ def lattice_reference(G, niter=5, D=None, connectivity=True, seed=None):
     G : graph
         The latticized graph.
 
+    Raises
+    ------
+    NetworkXError
+        If there are fewer than 4 nodes or 2 edges in `G`
+
     Notes
     -----
     The implementation is adapted from the algorithm by Sporns et al. [1]_.
@@ -160,7 +172,9 @@ def lattice_reference(G, niter=5, D=None, connectivity=True, seed=None):
     local_conn = nx.connectivity.local_edge_connectivity
 
     if len(G) < 4:
-        raise nx.NetworkXError("Graph has less than four nodes.")
+        raise nx.NetworkXError("Graph has fewer than four nodes.")
+    if len(G.edges) < 2:
+        raise nx.NetworkXError("Graph has fewer that 2 edges")
     # Instead of choosing uniformly at random from a generated edge list,
     # this algorithm chooses nonuniformly from the set of nodes with
     # probability weighted by degree.


Test patch:
diff --git a/networkx/algorithms/tests/test_smallworld.py b/networkx/algorithms/tests/test_smallworld.py
--- a/networkx/algorithms/tests/test_smallworld.py
+++ b/networkx/algorithms/tests/test_smallworld.py
@@ -68,3 +68,11 @@ def test_omega():
 
     for o in omegas:
         assert -1 <= o <= 1
+
+
+@pytest.mark.parametrize("f", (nx.random_reference, nx.lattice_reference))
+def test_graph_no_edges(f):
+    G = nx.Graph()
+    G.add_nodes_from([0, 1, 2, 3])
+    with pytest.raises(nx.NetworkXError, match="Graph has fewer that 2 edges"):
+        f(G)
Repository: networkx/networkx

Issue:
 Improve test coverage for algorithms in load centrality
<!-- If you have a general question about NetworkX, please use the discussions tab to create a new discussion -->

<!--- Provide a general summary of the issue in the Title above -->

Currently we don't have full coverage for the algorithms in load centrality. Code blocks which are highlighted with red at codcov https://app.codecov.io/gh/networkx/networkx/blob/main/networkx/algorithms/centrality/load.py don't have corresponding tests. The tests should be added in https://github.com/networkx/networkx/blob/main/networkx/algorithms/centrality/tests/test_load_centrality.py

### Current Behavior

<!--- Tell us what happens instead of the expected behavior -->

We don't test all the paths the code can take us.

### Expected Behavior

<!--- Tell us what should happen -->

We should be testing everything so there aren't any surprises.

### Steps to Reproduce

<!--- Provide a minimal example that reproduces the bug -->

Visit https://app.codecov.io/gh/networkx/networkx/blob/main/networkx/algorithms/centrality/load.py



Discussion:

Resolving patch:
diff --git a/networkx/algorithms/centrality/dispersion.py b/networkx/algorithms/centrality/dispersion.py
--- a/networkx/algorithms/centrality/dispersion.py
+++ b/networkx/algorithms/centrality/dispersion.py
@@ -19,6 +19,13 @@ def dispersion(G, u=None, v=None, normalized=True, alpha=1.0, b=0.0, c=0.0):
         The target of the dispersion score if specified.
     normalized : bool
         If True (default) normalize by the embededness of the nodes (u and v).
+    alpha, b, c : float
+        Parameters for the normalization procedure. When `normalized` is True,
+        the dispersion value is normalized by::
+
+            result = ((dispersion + b) ** alpha) / (embeddedness + c)
+
+        as long as the denominator is nonzero.
 
     Returns
     -------


Test patch:
Repository: networkx/networkx

Issue:
 Improve test coverage for algorithms in load centrality
<!-- If you have a general question about NetworkX, please use the discussions tab to create a new discussion -->

<!--- Provide a general summary of the issue in the Title above -->

Currently we don't have full coverage for the algorithms in load centrality. Code blocks which are highlighted with red at codcov https://app.codecov.io/gh/networkx/networkx/blob/main/networkx/algorithms/centrality/load.py don't have corresponding tests. The tests should be added in https://github.com/networkx/networkx/blob/main/networkx/algorithms/centrality/tests/test_load_centrality.py

### Current Behavior

<!--- Tell us what happens instead of the expected behavior -->

We don't test all the paths the code can take us.

### Expected Behavior

<!--- Tell us what should happen -->

We should be testing everything so there aren't any surprises.

### Steps to Reproduce

<!--- Provide a minimal example that reproduces the bug -->

Visit https://app.codecov.io/gh/networkx/networkx/blob/main/networkx/algorithms/centrality/load.py



Discussion:

Resolving patch:
diff --git a/networkx/algorithms/link_analysis/pagerank_alg.py b/networkx/algorithms/link_analysis/pagerank_alg.py
--- a/networkx/algorithms/link_analysis/pagerank_alg.py
+++ b/networkx/algorithms/link_analysis/pagerank_alg.py
@@ -44,6 +44,7 @@ def pagerank(
 
     tol : float, optional
       Error tolerance used to check convergence in power method solver.
+      The iteration will stop after a tolerance of ``len(G) * tol`` is reached.
 
     nstart : dictionary, optional
       Starting value of PageRank iteration for each node.
@@ -391,6 +392,7 @@ def _pagerank_scipy(
 
     tol : float, optional
       Error tolerance used to check convergence in power method solver.
+      The iteration will stop after a tolerance of ``len(G) * tol`` is reached.
 
     nstart : dictionary, optional
       Starting value of PageRank iteration for each node.


Test patch:
Repository: networkx/networkx

Issue:
doc: improve doc of possible values of `nodes` and expected behaviour
This is a note to update the documentation of functions that accept `nodes` kwarg, so that it's more explicit what the behaviour of the function is depending on the passed object.

Potentially, the docstrings would be adjusted with:
```
    nodes : node, iterable of nodes, or None (default=None)
        If a singleton node, return the number of triangles for that node. 
        If an iterable, compute the number of triangles for each of those nodes.
        If `None` (the default) compute the number of triangles for all nodes in `G`.
```

_Originally posted by @dschult in https://github.com/networkx/networkx/pull/6258#discussion_r1045180012_


Discussion:

Resolving patch:
diff --git a/networkx/algorithms/cluster.py b/networkx/algorithms/cluster.py
--- a/networkx/algorithms/cluster.py
+++ b/networkx/algorithms/cluster.py
@@ -329,8 +329,10 @@ def clustering(G, nodes=None, weight=None):
     ----------
     G : graph
 
-    nodes : container of nodes, optional (default=all nodes in G)
-       Compute clustering for nodes in this container.
+    nodes : node, iterable of nodes, or None (default=None)
+        If a singleton node, return the number of triangles for that node.
+        If an iterable, compute the number of triangles for each of those nodes.
+        If `None` (the default) compute the number of triangles for all nodes in `G`.
 
     weight : string or None, optional (default=None)
        The edge attribute that holds the numerical value used as a weight.


Test patch:
Repository: networkx/networkx

Issue:
Small documentation error in clustering coefficient for weighted networks
### Current Behavior

The networkx documenation gives the following formula for the clustering coefficient for unweighted directed networks: 
https://networkx.org/documentation/stable/reference/algorithms/generated/networkx.algorithms.cluster.clustering.html#networkx.algorithms.cluster.clustering

_Picture from networkx documenation_
![grafik](https://user-images.githubusercontent.com/31069329/212475513-479dec63-1dc9-4159-a83a-fb6da763b9c6.png)

Please note the factor 2 in the numerator. 
In the original publication the equation is the following: 

_Picture from original publication_
![grafik](https://user-images.githubusercontent.com/31069329/212475588-c43829cb-a819-4fad-8b50-ef3db1d02be1.png)
Please note the factor 2 in the denominator.

I checked the implementation and there it seems to be correct [here](https://github.com/networkx/networkx/blob/59f5b01c80064b3b88e1d044bab1c4cf61fdbc85/networkx/algorithms/cluster.py#L376) (great work to whoever made it so easy to compare it to the equation from the original publication 🎉 )

```python
t / ((dt * (dt - 1) - 2 * db) * 2)
```
Please note the factor two in the denominator.



### Expected Behavior
I think the equation in the documentation should be updated so that the 2 is in the denominator.


Discussion:

Resolving patch:
diff --git a/networkx/algorithms/cluster.py b/networkx/algorithms/cluster.py
--- a/networkx/algorithms/cluster.py
+++ b/networkx/algorithms/cluster.py
@@ -316,8 +316,7 @@ def clustering(G, nodes=None, weight=None):
 
     .. math::
 
-       c_u = \frac{2}{deg^{tot}(u)(deg^{tot}(u)-1) - 2deg^{\leftrightarrow}(u)}
-             T(u),
+       c_u = \frac{T(u)}{2(deg^{tot}(u)(deg^{tot}(u)-1) - 2deg^{\leftrightarrow}(u))},
 
     where :math:`T(u)` is the number of directed triangles through node
     :math:`u`, :math:`deg^{tot}(u)` is the sum of in degree and out degree of


Test patch:
Repository: networkx/networkx

Issue:
Reference for inverse_line_graph
There is a spelling mistake in the reference for the documentation of inverse_line_graph (latest version). 

https://networkx.org/documentation/stable/reference/generated/networkx.generators.line.inverse_line_graph.html

The author is "N. D. Roussopoulos" instead of N. Roussopolous (note the location of "ou"). Also, it would be nice to add a link or DOI to the article. The complete bibliographic info is below. 

@article{ROUSSOPOULOS1973108,
title = {A max {m,n} algorithm for determining the graph H from its line graph G},
journal = {Information Processing Letters},
volume = {2},
number = {4},
pages = {108-112},
year = {1973},
issn = {0020-0190},
doi = {https://doi.org/10.1016/0020-0190(73)90029-X},
url = {https://www.sciencedirect.com/science/article/pii/002001907390029X},
author = {Nicholas D. Roussopoulos},
keywords = {graph, maximal subgroup, complete graph, complete bipartite, automorphism}
}


Discussion:
Could you assign to me this issue?
I think I can't do that. Can somebody else do this? Possibly @rossbar? 
We don't usually use the "assign" function in Github to assign Issues.
Please open a PR with the fix for this issue and we will review it.
Thanks!
great thanks!
I'm sorry @barbireau I have a question with your dio link. It redirects me to a DOI not found when I click on it. I'm doing something wrong or the link is wrong ?
The DOI link should be without the "}" at the end. Github automaticaly makes the doi a clickable link, but adds the "}" by mistake. 

So the doi is 
https://doi.org/10.1016/0020-0190(73)90029-X
> I'm sorry @barbireau I have a question with your dio link. It redirects me to a DOI not found when I click on it. I'm doing something wrong or the link is wrong ?

ooh I got it, it took a square bracket as part of the link

Resolving patch:
diff --git a/networkx/generators/line.py b/networkx/generators/line.py
--- a/networkx/generators/line.py
+++ b/networkx/generators/line.py
@@ -243,7 +243,7 @@ def inverse_line_graph(G):
 
     Notes
     -----
-    This is an implementation of the Roussopoulos algorithm.
+    This is an implementation of the Roussopoulos algorithm[1]_.
 
     If G consists of multiple components, then the algorithm doesn't work.
     You should invert every component separately:
@@ -259,8 +259,9 @@ def inverse_line_graph(G):
 
     References
     ----------
-    * Roussopolous, N, "A max {m, n} algorithm for determining the graph H from
-      its line graph G", Information Processing Letters 2, (1973), 108--112.
+    .. [1] Roussopoulos, N.D. , "A max {m, n} algorithm for determining the graph H from
+       its line graph G", Information Processing Letters 2, (1973), 108--112, ISSN 0020-0190,
+       `DOI link <https://doi.org/10.1016/0020-0190(73)90029-X>`_
 
     """
     if G.number_of_nodes() == 0:


Test patch:
Repository: networkx/networkx

Issue:
rom_prufer_sequence report "ValueError: too many values to unpack"
### Current Behavior

If you try the following code
```
import networkx as nx
nx.from_prufer_sequence([7, 5, 5, 3, 1])
```
you will get
```
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/xing/miniconda3/lib/python3.9/site-packages/networkx/algorithms/tree/coding.py", line 396, in from_prufer_sequence
    u, v = orphans
ValueError: too many values to unpack (expected 2)
```

### Expected Behavior

The code should return a tree without any problem. See Applied Combinatorics by Mitchel T. Keller, William T. Trotter, [Chapter 5.6](https://www.rellek.net/book/s_graphs_counting-trees.html)


Discussion:
I think the sequence must have `n-2` values with numbers between 0 and n-1.  This has 5 values, so n=7. But the first number in the sequence is 7.  So this is an invalid sequence... Right?
I guess the error message could be more helpful. But first -- let's address the expected behavior question...
Should this return a tree?
I see. But node labels starting from 0 is not the convention in most math books, including [Wikipedia](https://en.wikipedia.org/wiki/Pr%C3%BCfer_sequence).

Anyway, better error would be helpful.
> I see. But node labels starting from 0 is not the convention in most math books, including [Wikipedia](https://en.wikipedia.org/wiki/Pr%C3%BCfer_sequence).

fwiw, the paper cited in the references of the implementation (https://www.scirp.org/journal/paperinformation.aspx?paperid=532) does use 0 to n - 1. Should be print a warning/error about this? Maybe catch the error when looking for orphans.

Resolving patch:
diff --git a/networkx/algorithms/tree/coding.py b/networkx/algorithms/tree/coding.py
--- a/networkx/algorithms/tree/coding.py
+++ b/networkx/algorithms/tree/coding.py
@@ -331,6 +331,11 @@ def from_prufer_sequence(sequence):
     NetworkX graph
         The tree corresponding to the given Prüfer sequence.
 
+    Raises
+    ------
+    NetworkXError
+        If the Prüfer sequence is not valid.
+
     Notes
     -----
     There is a bijection from labeled trees to Prüfer sequences. This
@@ -384,6 +389,11 @@ def from_prufer_sequence(sequence):
     not_orphaned = set()
     index = u = next(k for k in range(n) if degree[k] == 1)
     for v in sequence:
+        # check the validity of the prufer sequence
+        if v < 0 or v > n - 1:
+            raise nx.NetworkXError(
+                f"Invalid Prufer sequence: Values must be between 0 and {n-1}, got {v}"
+            )
         T.add_edge(u, v)
         not_orphaned.add(u)
         degree[v] -= 1


Test patch:
Repository: networkx/networkx

Issue:
Memory issue with read_graph6
<!-- If you have a general question about NetworkX, please use the discussions tab to create a new discussion -->

<!--- Provide a general summary of the issue in the Title above -->

I'm having memory issues when loading some moderately large graphs stored in the graph6 format (they were produced by `networkx` by the way, and neither generating them nor writing them to file using `write_graph6` raised any issue).
 
### Current Behavior

<!--- Tell us what happens instead of the expected behavior -->

When loading the file using `read_graph6`, all memory is quickly used up and the system will become unresponsive if I fail to kill `python`.

### Expected Behavior

<!--- Tell us what should happen -->

The file should be read and loaded into an `nx.Graph` object without any issue.

### Steps to Reproduce

<!--- Provide a minimal example that reproduces the bug -->
Decompress [the attached file](https://github.com/networkx/networkx/files/10989656/problematic-instance-for-read_graph6.g6.zip) (warning: decompressed file size is about 130M), open `top` in another terminal to "see" the problem, and then simply try to initialise the graph:

    >>> import networkx as nx
    >>> graph = nx.read_graph6("problematic-instance-for-read_graph6.g6")
    # be ready to kill the interpreter

### Environment

<!--- Please provide details about your local environment -->

Python version: 3.9.2
NetworkX version: 2.5
OS: Debian 11.6

### Additional context

The graph contains "only" 40.320 nodes and 564.480 edges, and `nauty-showg` has no problem displaying its contents in under a second. Smaller graphs of the same family yield no issue, but they're an order of magnitude smaller (the largest similar graph that poses no problem has 5.040 nodes and 52.920 edges).

If you have `nauty-showg`, you can load the graph without any issue as follows:

    >>> import subprocess
    >>> import networkx as nx
    >>> G = nx.Graph()
    >>> output = subprocess.check_output(("nauty-showg", "-l0", "problematic-instance-for-read_graph6.g6"))
    >>> for row in output.decode().split('\n')[2:]:
    ...    line = row.strip()[:-1].split()
    ...    G.add_edges_from((int(line[0]), int(x)) for x in line[2:])


<!--- Add any other context about the problem here, screenshots, etc. -->



Discussion:

Resolving patch:
diff --git a/networkx/readwrite/graph6.py b/networkx/readwrite/graph6.py
--- a/networkx/readwrite/graph6.py
+++ b/networkx/readwrite/graph6.py
@@ -121,7 +121,7 @@ def bits():
 
     G = nx.Graph()
     G.add_nodes_from(range(n))
-    for (i, j), b in zip([(i, j) for j in range(1, n) for i in range(j)], bits()):
+    for (i, j), b in zip(((i, j) for j in range(1, n) for i in range(j)), bits()):
         if b:
             G.add_edge(i, j)
 


Test patch: