GeezerVison

to_networkx built its DiGraph from the matrix's entries alone, so an
index whose row and column are both empty (a node with no edges)
vanished, and the nodes came out in the order the sorted entries first
named them. A 5x5 matrix with entries (0, 3), (2, 0) and (3, 3) became
a graph with nodes [0, 3, 2]; from_networkx then gave back a 3x3 matrix
with rows and columns permuted. viz.draw, which draws through to_networkx, left
such nodes out of the picture.

Add range(nrows) as nodes before the edges, so every row is a node and
the nodes iterate in index order, and from_networkx(to_networkx(M))
gives back M. The user guide's line on to_networkx said it always
labels the values "weight"; it now says what the nodes are and that
edge_attribute names (or drops) the values.

Making every row a node cannot work for a Matrix with huge dimensions:
for a 2**60 x 2**60 hypersparse Matrix, to_networkx would run out of
memory adding nodes (a DiGraph spends about 350 bytes on each).

create_isolates=False, from #476, makes nodes only of the indices that
have entries. They are still added in index order, so from_networkx
gives back the Matrix without its empty rows and columns. With the
default create_isolates=True, more than 2**40 rows raise ValueError
naming the keyword instead of exhausting memory; a graph that large
could never be built.

Behavior change: a non-square Matrix raises ValueError. Row i and
column i are both node i, which needs a square Matrix; a non-square one
gave a graph that mixed row and column indices. The docstring already
asked for a square Matrix.

Co-authored-by: Sultan Orazbayev <[email protected]>