handling the adjacency matrix of a graph in C++

Questions and problems about using polymake go here.
ren
Posts: 38
Joined: 03 May 2011, 15:21

handling the adjacency matrix of a graph in C++

Postby ren » 19 Aug 2013, 17:57

Hello,

I am stumbling over a problem when trying to compute the adjacency matrix of a graph in C++. Actually I am interested in the edges of a polytope, but - if I understand it correctly - an edge matrix itself does not exists as a subobject, but rather n alternate presentation of the adjacency matrix if you type "$p->GRAPH->EDGES;".

My problem occurs in the following lines:

Code: Select all

perl::Object g=p->give("GRAPH"); // p being a perl::Object storing a polytope IncidenceMatrix<NonSymmetric> icmat = g.give("ADJACENCY");
and the following message is displayed when I try to run it:
Size magic not implemented, <GEN5> line 37.
The problem most likely lies in me trying to store the adjacency matrix in an IncidenceMatrix. So I wanted to ask what type must I use here? I have also tried using set, but that also fails with the same message.

best regards and thanks in advance, Yue!

User avatar
gawrilow
Main Author
Posts: 423
Joined: 25 Dec 2010, 17:40

Re: handling the adjacency matrix of a graph in C++

Postby gawrilow » 19 Aug 2013, 20:39

You may indeed store the graph adjacency matrix in an IncidenceMatrix, but you must retrieve it correctly. The appropriate type to receive the "ADJACENCY" property is the C++ class Graph.

Code: Select all

Graph<> gr = p->give("GRAPH.ADJACENCY"); IncidenceMatrix<> adj = adjacency_matrix(gr);
As a matter of fact, adjacency_matrix(gr) gives you a reference to something which behaves pretty much like an IncidenceMatrix, thus if you are only going to study it, but not to modify, you can even avoid making a copy and work directly with that reference.

The mismatch between the C++ classes and the property name is admittedly confusing. We spent quite some time on inventing it, but could not find anything better. At the early days of polymake it was called simply "GRAPH", but as the graph became a fat subobject, the naming "GRAPH.GRAPH" was generally considered too ugly.


Return to “Helpdesk”