Plotting centrality
Centralization
{manynet} also implements network
+
{netrics} also implements network
centralization functions. Here we are no longer interested
in the level of the node, but in the level of the whole network, so the
@@ -459,10 +459,10 @@
Centralization
-
net_degree(ison_brandes)
-net_betweenness(ison_brandes)
-net_closeness(ison_brandes)
-print(net_eigenvector(ison_brandes), digits = 5)net_by_degree(ison_brandes)
+net_by_betweenness(ison_brandes)
+net_by_closeness(ison_brandes)
+print(net_by_eigenvector(ison_brandes), digits = 5)By default, scores are printed up to 3 decimal places, but this can be modified and, in any case, the unrounded values are retained @@ -484,18 +484,18 @@
Centralization
data-completion="1" data-diagnostics="1" data-startover="1" data-lines="0" data-pipe="|>">ison_brandes <- ison_brandes %>%
- add_node_attribute("degree", node_is_max(node_degree(ison_brandes))) %>%
- add_node_attribute("betweenness", node_is_max(node_betweenness(ison_brandes))) %>%
- add_node_attribute("closeness", node_is_max(node_closeness(ison_brandes))) %>%
- add_node_attribute("eigenvector", node_is_max(node_eigenvector(ison_brandes)))
+ add_node_attribute("degree", node_is_max(node_by_degree(ison_brandes))) %>%
+ add_node_attribute("betweenness", node_is_max(node_by_betweenness(ison_brandes))) %>%
+ add_node_attribute("closeness", node_is_max(node_by_closeness(ison_brandes))) %>%
+ add_node_attribute("eigenvector", node_is_max(node_by_eigenvector(ison_brandes)))
gd <- graphr(ison_brandes, node_color = "degree") +
- ggtitle("Degree", subtitle = round(net_degree(ison_brandes), 2))
+ ggtitle("Degree", subtitle = round(net_by_degree(ison_brandes), 2))
gc <- graphr(ison_brandes, node_color = "closeness") +
- ggtitle("Closeness", subtitle = round(net_closeness(ison_brandes), 2))
+ ggtitle("Closeness", subtitle = round(net_by_closeness(ison_brandes), 2))
gb <- graphr(ison_brandes, node_color = "betweenness") +
- ggtitle("Betweenness", subtitle = round(net_betweenness(ison_brandes), 2))
+ ggtitle("Betweenness", subtitle = round(net_by_betweenness(ison_brandes), 2))
ge <- graphr(ison_brandes, node_color = "eigenvector") +
- ggtitle("Eigenvector", subtitle = round(net_eigenvector(ison_brandes), 2))
+ ggtitle("Eigenvector", subtitle = round(net_by_eigenvector(ison_brandes), 2))
(gd | gb) / (gc | ge)
# ggsave("brandes-centralities.pdf")Glossary
@@ -622,12 +647,30 @@
@@ -764,7 +764,7 @@ There is no one single best community detection algorithm.
Instead there are several, each with their strengths and weaknesses.
Since this is a rather small network, we'll focus on the following methods:
walktrap, edge betweenness, and fast greedy.
-(Others are included in `{manynet}`/`{igraph}`)
+(Others are included in `{netrics}`/`{igraph}`)
As you use them, consider how they portray communities and consider which one(s)
afford a sensible view of the social world as cohesively organized.
@@ -819,13 +819,13 @@ which(friend_wt == 2)
```{r walk-hint-3, purl = FALSE}
# resulting in a modularity of
-net_modularity(friends, friend_wt)
+net_by_modularity(friends, friend_wt)
```
```{r walk-solution}
friend_wt <- node_in_walktrap(friends, times=50)
# results in a modularity of
-net_modularity(friends, friend_wt)
+net_by_modularity(friends, friend_wt)
```
We can also visualise the clusters on the original network
@@ -857,9 +857,9 @@ graphr(friends,
node_color = "walk_comm",
node_group = "walk_comm") +
ggtitle("Walktrap",
- subtitle = round(net_modularity(friends, friend_wt), 3))
+ subtitle = round(net_by_modularity(friends, friend_wt), 3))
# the function `round()` rounds the values to a specified number of decimal places
-# here, we are telling it to round the net_modularity score to 3 decimal places,
+# here, we are telling it to round the net_by_modularity score to 3 decimal places,
# but the score is exactly 0.27 so only two decimal places are printed.
```
@@ -874,7 +874,7 @@ graphr(friends,
node_color = "walk_comm",
node_group = "walk_comm") +
ggtitle("Walktrap",
- subtitle = round(net_modularity(friends, friend_wt), 3))
+ subtitle = round(net_by_modularity(friends, friend_wt), 3))
```
This can be helpful when polygons overlap to better identify membership
@@ -924,7 +924,7 @@ graphr(friends,
node_color = "eb_comm",
node_group = "eb_comm") +
ggtitle("Edge-betweenness",
- subtitle = round(net_modularity(friends, friend_eb), 3))
+ subtitle = round(net_by_modularity(friends, friend_eb), 3))
```
```{r ebplot-solution}
@@ -934,7 +934,7 @@ graphr(friends,
node_color = "eb_comm",
node_group = "eb_comm") +
ggtitle("Edge-betweenness",
- subtitle = round(net_modularity(friends, friend_eb), 3))
+ subtitle = round(net_by_modularity(friends, friend_eb), 3))
```
For more on this algorithm, see M Newman and M Girvan: Finding and
@@ -959,7 +959,7 @@ although I personally find it both useful and in many cases quite "accurate".
```{r fg-hint-1, purl = FALSE}
friend_fg <- node_in_greedy(friends)
friend_fg # Does this result in a different community partition?
-net_modularity(friends, friend_fg) # Compare this to the edge betweenness procedure
+net_by_modularity(friends, friend_fg) # Compare this to the edge betweenness procedure
```
```{r fg-hint-2, purl = FALSE}
@@ -970,14 +970,14 @@ graphr(friends,
node_color = "fg_comm",
node_group = "fg_comm") +
ggtitle("Fast-greedy",
- subtitle = round(net_modularity(friends, friend_fg), 3))
+ subtitle = round(net_by_modularity(friends, friend_fg), 3))
#
```
```{r fg-solution}
friend_fg <- node_in_greedy(friends)
friend_fg # Does this result in a different community partition?
-net_modularity(friends, friend_fg) # Compare this to the edge betweenness procedure
+net_by_modularity(friends, friend_fg) # Compare this to the edge betweenness procedure
# Again, we can visualise these communities in different ways:
friends <- friends %>%
@@ -986,7 +986,7 @@ graphr(friends,
node_color = "fg_comm",
node_group = "fg_comm") +
ggtitle("Fast-greedy",
- subtitle = round(net_modularity(friends, friend_fg), 3))
+ subtitle = round(net_by_modularity(friends, friend_fg), 3))
```
See A Clauset, MEJ Newman, C Moore:
@@ -1005,7 +1005,7 @@ question("What is the difference between communities and components?",
### Communities
-Lastly, `{manynet}` includes a function to run through and find the membership
+Lastly, `{netrics}` includes a function to run through and find the membership
assignment that maximises `r gloss("modularity")` across any of the applicable community
detection procedures.
This is helpfully called `node_in_community()`.
diff --git a/inst/tutorials/tutorial4/community.html b/inst/tutorials/tutorial4/community.html
index fda2a0e..37264f3 100644
--- a/inst/tutorials/tutorial4/community.html
+++ b/inst/tutorials/tutorial4/community.html
@@ -13,7 +13,7 @@
-
+
-For this session, we're going to use the "ison_algebra" dataset included in the `{manynet}` package.
+For this session, we're going to use the "ison_algebra" dataset included in the `{netrics}` package.
Do you remember how to call the data?
Can you find out some more information about it via its help file?
@@ -204,7 +204,7 @@ there are no bridges.
```{r bridges, exercise = TRUE, exercise.setup = "objects-setup"}
sum(tie_is_bridge(friends))
-any(node_bridges(friends)>0)
+any(node_by_bridges(friends)>0)
```
### Constraint
@@ -212,7 +212,7 @@ any(node_bridges(friends)>0)
But some nodes do seem more deeply embedded in the network than others.
Let's take a look at which actors are least `r gloss("constrained", "constraint")`
by their position in the *task* network.
-`{manynet}` makes this easy enough with the `node_constraint()` function.
+`{netrics}` makes this easy enough with the `node_by_constraint()` function.
```{r objects-setup, purl=FALSE}
alge <- to_named(ison_algebra)
@@ -226,12 +226,12 @@ tasks <- to_uniplex(alge, "tasks")
```
```{r constraint-hint, purl = FALSE}
-node_constraint(____)
+node_by_constraint(____)
# Don't forget we want to look at which actors are least constrained by their position in the 'tasks' network
```
```{r constraint-solution}
-node_constraint(tasks)
+node_by_constraint(tasks)
```
This function returns a vector of constraint scores that can range between 0 and 1.
@@ -244,8 +244,8 @@ We can also identify the node with the minimum constraint score using `node_is_m
```{r constraintplot-hint-1, purl = FALSE}
tasks <- tasks %>%
- mutate(constraint = node_constraint(____),
- low_constraint = node_is_min(node_constraint(____)))
+ mutate(constraint = node_by_constraint(____),
+ low_constraint = node_is_min(node_by_constraint(____)))
# Don't forget, we are still looking at the 'tasks' network
```
@@ -264,8 +264,8 @@ graphr(tasks, node_size = "constraint", node_color = "low_constraint")
```{r constraintplot-solution}
tasks <- tasks %>%
- mutate(constraint = node_constraint(tasks),
- low_constraint = node_is_min(node_constraint(tasks)))
+ mutate(constraint = node_by_constraint(tasks),
+ low_constraint = node_is_min(node_by_constraint(tasks)))
graphr(tasks, node_size = "constraint", node_color = "low_constraint")
```
@@ -318,7 +318,7 @@ a uniplex subgraph thereof.
### Finding structurally equivalent classes
-In `{manynet}`, finding how the nodes of a network can be partitioned
+In `{netrics}`, finding how the nodes of a network can be partitioned
into structurally equivalent classes can be as easy as:
```{r find-se, exercise = TRUE, exercise.setup = "data"}
@@ -337,8 +337,8 @@ how these classes are identified and how to interpret them.
### Step one: starting with a census
All equivalence classes are based on nodes' similarity across some profile of motifs.
-In `{manynet}`, we call these motif *censuses*.
-Any kind of census can be used, and `{manynet}` includes a few options,
+In `{netrics}`, we call these motif *censuses*.
+Any kind of census can be used, and `{netrics}` includes a few options,
but `node_in_structural()` is based off of the census of all the nodes' ties,
both outgoing and incoming ties, to characterise their relationships to tie partners.
@@ -347,24 +347,24 @@ both outgoing and incoming ties, to characterise their relationships to tie part
```
```{r construct-cor-hint-1, purl = FALSE}
-# Let's use the node_by_tie() function
+# Let's use the node_x_tie() function
# The function accepts an object such as a dataset
# Hint: Which dataset are we using in this tutorial?
-node_by_tie(____)
+node_x_tie(____)
```
```{r construct-cor-hint-2, purl = FALSE}
-node_by_tie(ison_algebra)
+node_x_tie(ison_algebra)
```
```{r construct-cor-hint-3, purl = FALSE}
# Now, let's get the dimensions of an object via the dim() function
-dim(node_by_tie(ison_algebra))
+dim(node_x_tie(ison_algebra))
```
```{r construct-cor-solution}
-node_by_tie(ison_algebra)
-dim(node_by_tie(ison_algebra))
+node_x_tie(ison_algebra)
+dim(node_x_tie(ison_algebra))
```
We can see that the result is a matrix of 16 rows and 96 columns,
@@ -379,7 +379,7 @@ what would you do if you wanted it to be binary?
```{r construct-binary-hint, purl = FALSE}
# we could convert the result using as.matrix, returning the ties
-as.matrix((node_by_tie(ison_algebra)>0)+0)
+as.matrix((node_x_tie(ison_algebra)>0)+0)
```
@@ -388,17 +388,17 @@ as.matrix((node_by_tie(ison_algebra)>0)+0)
# Note that this also reduces the total number of possible paths between nodes
ison_algebra %>%
select_ties(-type) %>%
- node_by_tie()
+ node_x_tie()
```
-Note that `node_by_tie()` does not need to be passed to `node_in_structural()` ---
+Note that `node_x_tie()` does not need to be passed to `node_in_structural()` ---
this is done automatically!
However, the more generic `node_in_equivalence()` is available and can be used
-with whichever census (`node_by_*()` output) is desired.
-Feel free to explore using some of the other censuses available in `{manynet}`,
+with whichever census (`node_x_*()` output) is desired.
+Feel free to explore using some of the other censuses available in `{netrics}`,
though some common ones are already used in the other equivalence convenience functions,
-e.g. `node_by_triad()` in `node_in_regular()`
-and `node_by_path()` in `node_in_automorphic()`.
+e.g. `node_x_triad()` in `node_in_regular()`
+and `node_x_path()` in `node_in_automorphic()`.
### Step two: growing a tree of similarity
@@ -413,7 +413,7 @@ so that help page should be consulted for more details.
By default `"euclidean"` is used.
Second, we can also set the type of clustering algorithm employed.
-By default, `{manynet}`'s equivalence functions use `r gloss("hierarchical clustering","hierclust")`, `"hier"`,
+By default, `{netrics}`'s equivalence functions use `r gloss("hierarchical clustering","hierclust")`, `"hier"`,
but for compatibility and enthusiasts, we also offer `"concor"`,
which implements a CONCOR (CONvergence of CORrelations) algorithm.
@@ -438,7 +438,7 @@ question("Do you see any differences?",
allow_retry = TRUE)
```
-So plotting a `membership` vector from `{manynet}` returns a dendrogram
+So plotting a `membership` vector from `{netrics}` returns a dendrogram
with the names of the nodes on the _y_-axis and the distance between them on the _x_-axis.
Using the census as material, the distances between the nodes
is used to create a dendrogram of (dis)similarity among the nodes.
@@ -469,7 +469,7 @@ But where does this red line come from?
Or, more technically, how do we identify the number of clusters
into which to assign nodes?
-`{manynet}` includes several different ways of establishing `k`,
+`{netrics}` includes several different ways of establishing `k`,
or the number of clusters.
Remember, the further to the right the red line is
(the lower on the tree the cut point is)
@@ -507,7 +507,7 @@ then we might expect there to be a relatively rapid increase
in correlation as we move from, for example, 3 clusters to 4 clusters,
but a relatively small increase from, for example, 13 clusters to 14 clusters.
By identifying the inflection point in this line graph,
-`{manynet}` selects a number of clusters that represents a trade-off
+`{netrics}` selects a number of clusters that represents a trade-off
between fit and parsimony.
This is the `k = "elbow"` method.
@@ -535,12 +535,12 @@ Either is probably fine here,
and there is much debate around how to select the number of clusters anyway.
However, the silhouette method seems to do a better job of identifying
how unique the 16th node is.
-The silhouette method is also the default in `{manynet}`.
+The silhouette method is also the default in `{netrics}`.
Note that there is a somewhat hidden parameter here, `range`.
Since testing across all possible numbers of clusters can get
computationally expensive (not to mention uninterpretable) for large networks,
-`{manynet}` only considers up to 8 clusters by default.
+`{netrics}` only considers up to 8 clusters by default.
This however can be modified to be higher or lower, e.g. `range = 16`.
Finally, one last option is `k = "strict"`,
@@ -597,14 +597,14 @@ but this can be tweaked by assigning some other summary statistic as `FUN = `.
```
```{r summ-hint, purl = FALSE}
-# Let's wrap node_by_tie inside the summary() function
+# Let's wrap node_x_tie inside the summary() function
# and pass it a membership result
-summary(node_by_tie(____),
+summary(node_x_tie(____),
membership = ____)
```
```{r summ-solution}
-summary(node_by_tie(alge),
+summary(node_x_tie(alge),
membership = node_in_structural(alge))
```
diff --git a/inst/tutorials/tutorial5/position.html b/inst/tutorials/tutorial5/position.html
index 54a6232..8426eef 100644
--- a/inst/tutorials/tutorial5/position.html
+++ b/inst/tutorials/tutorial5/position.html
@@ -13,7 +13,7 @@
-
+