Open rsbivand opened 2 weeks ago
Thanks for the notification Roger.
I've read through the discussion on the spdep github page. From what I gather, the following will still be okay:
class(G) <- "Graph"
nb2 <- spdep::n.comp.nb(spdep::graph2nb(G))
I'm using the comp.id
values returned by n.comp.nb
, so I (currently) plan to keep this as is unless I'm missing something.
Thanks again
At
https://github.com/r-spatial/spdep/blob/a0a7d030ff836c396e80d61a30a26ae477d62433/R/graph2nb.R#L35-L39
spdep::graph2nb
already creates the object returned by spdep::n.comp.nb
if the default is followed and if the sum of the number of nodes and the number of edges is less than 100000, in the development version of spdep
, so:
class(G) <- "Graph"
G1 <- spdep::graph2nb(G)
nb2 <- attr(G1, "ncomp")
if (is.null(nb2)) {
nb2 <- spdep::n.comp.nb(G1)
}
The underlying problem was that for largish node counts and very dense neighbour sets, spdep::n.comp.nb
could run for an unexpectedly long time, and that the subgraph count was recently added to the print.nb
method.
I see, great! Thanks, I'll use that
In https://github.com/r-spatial/spdep/issues/160 and https://github.com/r-spatial/spdep/pull/161, changes are made to the use of
n.comp.nb
. It seems now more important to move checks of the possible existence of disjoint subgraphs to the creation and modification ofnb
neighbour objects, adding these to thenb
object at creation or modification inspdep
. This means that separate checking may be carried out on the"ncomp"
attribute of annb
object fromspdep
version >= 1.3-6 (branch n_comp until https://github.com/r-spatial/spdep/pull/161 is merged).geostan
usesn.comp.nb
in: R/convenience-functions.R, so for larger and/or denser neighbour objects will benefit from the upcoming changes.