For 2.0, we removed string matrix support from graph to adjacency matrix conversion functions (TODO: find discussion). They are not supported with either sparse or dense matrices.
> g <- make_graph(c(1,2, 2,3), n=4)
> E(g)$foo <- c('a', 'b')
> A <- as_adjacency_matrix(g, attr='foo')
Error in get.adjacency.sparse(graph, type = type, attr = attr, names = names) :
Matrices must be either numeric or logical, and the edge attribute is notWe should also remove it for biadjacency matrix functions, for consistency.
Note that the current support with dense matrices is arguably broken:
> as_biadjacency_matrix(g, types=c(T,F,T,F), attr='foo')
1 3
2 "a" "b"
4 "0" "0"
The string "0" makes no sense as the null element of a string matrix.
Sparse support does not work at all:
as_biadjacency_matrix(g, types=c(T,F,T,F), attr='foo', sparse=T)
Error in getClass(Class, where = topenv(parent.frame())) :
“gTMatrix” is not a defined class
Finally, the C core does not support string matrices (dense or sparse), and is very unlikely to ever get support. Ideally, we will rely on C core functions for all (bi)adacency matrix functionality, so we should stick to numeric matrices.
Note that string matrices are conceptually very different from numeric ones as it is unclear how to handle multi-edges and undirected self-loops, which require composing attribute values together for graph -> matrix conversions, and splitting for matrix -> graph conversions.
CC @maelle @krlmlr @schochastics
For 2.0, we removed string matrix support from graph to adjacency matrix conversion functions (TODO: find discussion). They are not supported with either sparse or dense matrices.
We should also remove it for biadjacency matrix functions, for consistency.
Note that the current support with dense matrices is arguably broken:
The string
"0"makes no sense as the null element of a string matrix.Sparse support does not work at all:
Finally, the C core does not support string matrices (dense or sparse), and is very unlikely to ever get support. Ideally, we will rely on C core functions for all (bi)adacency matrix functionality, so we should stick to numeric matrices.
Note that string matrices are conceptually very different from numeric ones as it is unclear how to handle multi-edges and undirected self-loops, which require composing attribute values together for graph -> matrix conversions, and splitting for matrix -> graph conversions.
CC @maelle @krlmlr @schochastics