Describe the bug
The docs for alpha_centrality() say that the weights argument is
A character scalar that gives the name of the edge attribute to use in the adjacency matrix. If it is NULL, then the ‘weight’ edge attribute of the graph is used, if there is one. Otherwise, or if it is NA, then the calculation uses the standard adjacency matrix.
The function seems to work properly when the weights argument is "weight", NULL, or NA, but crashes when it's anything else.
The problem seems to be with one or more conditions in the block of ifs in both the dense and sparse functions:
|
if (is.null(weights) && "weight" %in% edge_attr_names(graph)) { |
|
if (is.null(weights) && "weight" %in% edge_attr_names(graph)) { |
It looks like the lines that go wrong were introduced in 81e82d8 and/or 4dda4fd.
#910 might obviate the need for this in the long term, so any fix might be temporary (but this logic shouldn't be reused without edits in the meantime, e.g., in #905).
To reproduce
library(igraph)
#>
#> Attaching package: 'igraph'
#> The following objects are masked from 'package:stats':
#>
#> decompose, spectrum
#> The following object is masked from 'package:base':
#>
#> union
star <- make_star(10)
E(star)$myweight <- sample(ecount(star))
alpha_centrality(star, weights = "myweight", sparse = TRUE)
#> Error in h(simpleError(msg, call)): error in evaluating the argument 'x' in selecting a method for function 't': no such edge attribute
Created on 2023-10-21 with reprex v2.0.2
Version information
- R/igraph version: 1.5.1
- R version: 4.1.2 (2021-11-01)
- Operating system: Ubuntu 20.04.6 LTS
> sessionInfo()
R version 4.1.2 (2021-11-01)
Platform: x86_64-pc-linux-gnu (64-bit)
Running under: Ubuntu 20.04.6 LTS
Matrix products: default
BLAS: /usr/lib/x86_64-linux-gnu/openblas-pthread/libblas.so.3
LAPACK: /usr/lib/x86_64-linux-gnu/openblas-pthread/liblapack.so.3
locale:
[1] LC_CTYPE=en_US.UTF-8 LC_NUMERIC=C
[3] LC_TIME=en_US.UTF-8 LC_COLLATE=en_US.UTF-8
[5] LC_MONETARY=en_US.UTF-8 LC_MESSAGES=en_US.UTF-8
[7] LC_PAPER=en_US.UTF-8 LC_NAME=C
[9] LC_ADDRESS=C LC_TELEPHONE=C
[11] LC_MEASUREMENT=en_US.UTF-8 LC_IDENTIFICATION=C
attached base packages:
[1] stats graphics grDevices utils datasets methods base
other attached packages:
[1] igraph_1.5.1
loaded via a namespace (and not attached):
[1] viridis_0.6.4 pkgload_1.3.3 tidyr_1.3.0 tidygraph_1.2.3
[5] viridisLite_0.4.2 R.utils_2.12.2 ggraph_2.1.0 shiny_1.7.5.1
[9] yaml_2.3.7 remotes_2.4.2.1 ggrepel_0.9.4 sessioninfo_1.2.2
[13] lattice_0.20-45 pillar_1.9.0 glue_1.6.2 digest_0.6.33
[17] promises_1.2.1 polyclip_1.10-6 colorspace_2.1-0 Matrix_1.6-1.1
[21] R.oo_1.25.0 htmltools_0.5.6.1 httpuv_1.6.11 clipr_0.8.0
[25] pkgconfig_2.0.3 devtools_2.4.5 haven_2.5.3 unix_1.5.5
[29] purrr_1.0.2 xtable_1.8-4 scales_1.2.1 processx_3.8.2
[33] tweenr_2.0.2 later_1.3.1 ggforce_0.4.1 tibble_3.2.1
[37] styler_1.10.2 generics_0.1.3 farver_2.1.1 ggplot2_3.4.4
[41] usethis_2.2.2 ellipsis_0.3.2 cachem_1.0.8 withr_2.5.1
[45] cli_3.6.1 magrittr_2.0.3 crayon_1.5.2 mime_0.12
[49] memoise_2.0.1 evaluate_0.22 ps_1.7.5 R.methodsS3_1.8.2
[53] fs_1.6.3 fansi_1.0.5 R.cache_0.16.0 MASS_7.3-55
[57] forcats_1.0.0 pkgbuild_1.4.2 profvis_0.3.8 tools_4.1.2
[61] prettyunits_1.2.0 hms_1.1.3 lifecycle_1.0.3 stringr_1.5.0
[65] munsell_0.5.0 reprex_2.0.2 callr_3.7.3 compiler_4.1.2
[69] rlang_1.1.1 grid_4.1.2 rstudioapi_0.15.0 htmlwidgets_1.6.2
[73] miniUI_0.1.1.1 corrr_0.4.4 rmarkdown_2.25 gtable_0.3.4
[77] graphlayouts_1.0.1 R6_2.5.1 gridExtra_2.3 knitr_1.44
[81] dplyr_1.1.3 fastmap_1.1.1 utf8_1.2.3 stringi_1.7.12
[85] Rcpp_1.0.11 vctrs_0.6.4 tidyselect_1.2.0 xfun_0.40
[89] urlchecker_1.0.1
Describe the bug
The docs for
alpha_centrality()say that theweightsargument isThe function seems to work properly when the
weightsargument is "weight",NULL, orNA, but crashes when it's anything else.The problem seems to be with one or more conditions in the block of
ifs in both the dense and sparse functions:rigraph/R/centrality.R
Line 1260 in 2810da8
rigraph/R/centrality.R
Line 1301 in 2810da8
It looks like the lines that go wrong were introduced in 81e82d8 and/or 4dda4fd.
#910 might obviate the need for this in the long term, so any fix might be temporary (but this logic shouldn't be reused without edits in the meantime, e.g., in #905).
To reproduce
Created on 2023-10-21 with reprex v2.0.2
Version information