Repository: networkx/networkx

Issue:
Bipartite Closeness centrality algorithm does not report nodes with zero value.
### Current Behavior
The function saves closeness values of '0.0' always at closeness[len(nodes)] which is closeness[n]. This results a returned dictionary with less elements than number of nodes in the graph.

### Expected Behavior
The values of '0.0' should instead be saved at closeness[node] within the for-loops iterating over all nodes.

### Steps to Reproduce
/

### Environment
Python version: 3.9.12
NetworkX version: 2.8


### Additional context
In both cases within the source code below
`else:
            closeness[n] = 0.
`
needs to be changed to:
`else:
            closeness[node] = 0.
`
See sourcecode:
https://networkx.org/documentation/stable/_modules/networkx/algorithms/bipartite/centrality.html#closeness_centrality
Bipartite Closeness centrality algorithm does not report nodes with zero value.
### Current Behavior
The function saves closeness values of '0.0' always at closeness[len(nodes)] which is closeness[n]. This results a returned dictionary with less elements than number of nodes in the graph.

### Expected Behavior
The values of '0.0' should instead be saved at closeness[node] within the for-loops iterating over all nodes.

### Steps to Reproduce
/

### Environment
Python version: 3.9.12
NetworkX version: 2.8


### Additional context
In both cases within the source code below
`else:
            closeness[n] = 0.
`
needs to be changed to:
`else:
            closeness[node] = 0.
`
See sourcecode:
https://networkx.org/documentation/stable/_modules/networkx/algorithms/bipartite/centrality.html#closeness_centrality


Discussion:
The docstring states that 

    The closeness of a node is the distance to all other nodes in the 
    graph or in the case that the graph is not connected to all other nodes
    in the connected component containing that node.

So, I think we don't intend to report nodes that are not connected to the other nodes. Isn't that the intent of this part of the code?  If I am missing something (and even if not) can you provide a small example where the resulting dict is not what you would expect?  That is the first step toward getting a test to show this difficulty. (and thus the first step toward a fix. :}
In the docstring it also states that: 

> Notes
>     -----
>     The nodes input parameter must contain all nodes in one bipartite node set,
>     but the dictionary returned contains all nodes from both node sets.
> 

I might try to provide an example at some point when I have time, but it should be fine without one..

The function saves multiple calulated closeness values at closeness[n], which can't be what was intended.
    
Ahh... yes, I understand ---  it looks like a typo, that should be `node` instead of `n` in two places.
And you said that in the original post. I was too focused on it being the bipartite and not the regular closeness centrality that I missed that.  

Yes, that code appears to simply avoid dividing by zero. And instead it assigns a value to a nonexisting node.
Thanks!
The docstring states that 

    The closeness of a node is the distance to all other nodes in the 
    graph or in the case that the graph is not connected to all other nodes
    in the connected component containing that node.

So, I think we don't intend to report nodes that are not connected to the other nodes. Isn't that the intent of this part of the code?  If I am missing something (and even if not) can you provide a small example where the resulting dict is not what you would expect?  That is the first step toward getting a test to show this difficulty. (and thus the first step toward a fix. :}
In the docstring it also states that: 

> Notes
>     -----
>     The nodes input parameter must contain all nodes in one bipartite node set,
>     but the dictionary returned contains all nodes from both node sets.
> 

I might try to provide an example at some point when I have time, but it should be fine without one..

The function saves multiple calulated closeness values at closeness[n], which can't be what was intended.
    
Ahh... yes, I understand ---  it looks like a typo, that should be `node` instead of `n` in two places.
And you said that in the original post. I was too focused on it being the bipartite and not the regular closeness centrality that I missed that.  

Yes, that code appears to simply avoid dividing by zero. And instead it assigns a value to a nonexisting node.
Thanks!

Resolving patch:
diff --git a/networkx/algorithms/bipartite/centrality.py b/networkx/algorithms/bipartite/centrality.py
--- a/networkx/algorithms/bipartite/centrality.py
+++ b/networkx/algorithms/bipartite/centrality.py
@@ -252,7 +252,7 @@ def closeness_centrality(G, nodes, normalized=True):
                 s = (len(sp) - 1) / (len(G) - 1)
                 closeness[node] *= s
         else:
-            closeness[n] = 0.0
+            closeness[node] = 0.0
     for node in bottom:
         sp = dict(path_length(G, node))
         totsp = sum(sp.values())
@@ -262,5 +262,5 @@ def closeness_centrality(G, nodes, normalized=True):
                 s = (len(sp) - 1) / (len(G) - 1)
                 closeness[node] *= s
         else:
-            closeness[n] = 0.0
+            closeness[node] = 0.0
     return closeness


Test patch:
diff --git a/networkx/algorithms/bipartite/tests/test_centrality.py b/networkx/algorithms/bipartite/tests/test_centrality.py
--- a/networkx/algorithms/bipartite/tests/test_centrality.py
+++ b/networkx/algorithms/bipartite/tests/test_centrality.py
@@ -51,9 +51,9 @@ def test_closeness_centrality(self):
         G.add_node(0)
         G.add_node(1)
         c = bipartite.closeness_centrality(G, [0])
-        assert c == {1: 0.0}
+        assert c == {0: 0.0, 1: 0.0}
         c = bipartite.closeness_centrality(G, [1])
-        assert c == {1: 0.0}
+        assert c == {0: 0.0, 1: 0.0}
 
     def test_davis_degree_centrality(self):
         G = self.davis