I know that there are many techniques to represent graphs.
Suppose I have a directed massive 3D graph with 100,000 nodes at maximum.
Suppose the graph looks somewhat like the following:
Suppose each node of the graph has three pieces of information:
A 30-character string as a label
floating point values as coordinates
three integer values
The graph is dynamic. I.e., connections frequently change, and the nodes frequently change their coordinates.
What would be the most efficient way to represent this graph in computer memory so that I can apply mathematical operations on each node?
Should I use data structures, or should I use big-data analytics or ML?
Related
I have a set of disconnected graphs, each one represented by a set of triples (head, edge, tail).
Given a new graph, I want to find which graph in the forest is structurally most similar to the new graph.
I am able to create feature vectors representing individual nodes and edges for each graph, but I dont understand how to represent and use them for the purpose of finding similarity.
I have found a partitioning algorithm that works on hypergraphs and its name is hMETIS, but my input is in the form of a simple weighted graph. Is there any technique that maps a graph to a hypergraph?
In general: No.
A graph contains information on binary interactions between two vertices, and there is no way to extract the information about the higher order interactions.
In short, if I give you a hypergraph I can use (multiple methods) to turn it into a graph, but that graph could be the result of multiple hypergraphs.
There are a few exceptions to this, notably if you have more information about the vertices outside of the graph, or if the graph is bipartite.
There are many theories about calculating of graph similarity such as vertex edge overlap, jacard, co-sine, edit distance, signature similarity, lambda distance, deltacon so on. These things are based on single edge of the graph. But there are many graphs having multiple edges in real world.
Given similar two graphs like above, how could we calculate graph similarity?
Using previous graph similarity, there are only 2-dimension vector and the entry is just scalar that is number, but in multiple edge's graph, the entry should be tuple. Because there are one more actions between nodes. For the previous method, it could be called who-knows-whom schem, but latter graph, it could be said who-knows-whom*-how*. I think the previous mothods could be used for the multiple edge's graph easily, so there aren't logic or methods about it.
Thanks in advance!
There is not "the" way yo compute graph similarity.
Depending on your data and problem, very different approaches may be good. In many cases, simply merging the two edges into one makes perfect sense. For example, if I have two roads of capacity x and y to go from A to B - for many analyses this is comparable to having just one rode, with the combined capacity.
I would like to test if the geographical location of my vertices (ie I have a matrix giving the distance between each pair of actors of my network) has an influence on the presence/absence of edges. If I have correctly understood, this feature is called propinquity....
In other words, I would like to know if two vertices are more likely (or less likely) to be connected if their distance is small.
Do you have any idea of how to do that in R? I usually use igraph but if another library does that I will use it of course :-).
I want to know what will be an efficient way to implement an undirected weighted graph. I want to perform Prims and Kruskal algorithms on it. I know about adjacency lists but wouldn't that waste memory; for eg. lets suppose I have two vertexes A and B connected by an edge with weight 'x', so I'll need to add two entries in the adjacency list:
A,B,x
B,A,x
Am I missing something?
Adjacency lists are the memory-efficient way of implementing graphs, rather than adjacency matrices.
Actually, you have two options here.
If you want less time and more memory, you should do what you've written.
If you want more time and less memory, you could implement your edges A,B,x where A>B. But then, you would spend a lot of time while getting the adjacent vertices of any vertex.
It's your call. But second bullet is not preferred if you're dealing with less than millions of nodes.
since the graph is undirected I guess you will need only one edge between the nodes A and B