What is the preferred way to convert a weighted adjacency matrix into a graphNEL object? I typically try to use

as(adj, "graphNEL")

but this tends to fail on edge cases. For example, it does not allow negative edge weights (not sure why this is a problem). Also, since edgemode cannot be directly set (I think?), I cannot specify if it is directed or undirected. Both of these issues can be hacked around in various ways, but I am curious what the maintainers / developers intend for this.

Long story short, what is the intended method to take a weighted adjacency matrix and coerce it to a graphNEL object?

Thanks!

Dear Bryon

I am not sure there is "the intended method". Most of the code in this package is >10 years old, and it was contributed by several authors at the time. So, contributions and patches from you will also be welcome.

Some observations that might be useful:

• as(adj, "graphNEL") with adj a matrix proceeds via matrix -> graphAM -> graphNEL (look for setAs("matrix", "graphNEL") in mat2graph.R), and for setAs(from="graphAM", to="graphNEL") in methods-graphAM.R. None of that code is set in stone, nor is it very complicated, and patches are welcome.
• There is also the function ftM2graphNEL (which internally invokes .ftM2other), and this might be closer to what you need. (ftM stands for 'from-to-matrix', and the design idea at the time was to implement the core functionality as normal R functions and only in a second layer wrap them into S4 methods.) The transformation from adjacency matrix to from-to-matrix is simple (essentially, which(aM!=0, arr.ind=TRUE)). In any case, also that function is simple and you could modify it to your needs.
• And then there is aM2bpG, which is intended for bipartite graphs (i.e. the matrix can be non-square and is expected to have different sets of row and column names) - but there I noted a line that assumes positive edge weights, for no obvious reason, and simply replacing a > operator with an != should generalize that.

Another question is whether you have to use the graph package. There are more actively maintained packages with overlapping aims (e.g. the igraph package on CRAN) - which is part of the reasons why graph authors have decided to maintain, but not further develop the latter.

Hope this helps

Wolfgang