I've been trying to find a way to replicate the following network graph format in R using DiagrammeR/GraphViz, but without success (ignore the thick black arrow on N1): https://i.stack.imgur.com/oHpQz.png
The graph is a directed graph and each edge in a certain direction either ends with an arrowhead (-->) if the edge value is positive, or a circle/odot (--o) if the edge value is negative. Between a pair of nodes (ex. N1 -- A1), there can be an edge N1 --> A1 and an edge A1 --o N1, and these need to be concentrated so that the two edges look like one line with an arrowhead on one end and a circlehead on the opposite end (like this: o--->). These cannot be parallel or look like two edges ideally.
Another requirement is that the nodes have to be in very specific positions and remain there throughout model simulations where edges might change. From what I have tried and the documentation I have read, this is not possible to do in DOT format, but is possible in neato format.
This is where I get a problem. In neato, I can align the nodes exactly where I want them by defining their x,y positions. However, when I use concentrate = true to create the o---> edge from two otherwise parallel edges, only one type of arrowhead remains. So an edge that's supposed to look like o---> ends up looking like ---> or o---.
This is not a problem in DOT format as concentrate = true does what I want it to do, but in DOT I cannot assign exact node positions. I have tried getting around this using node ranks but without much luck. It seems to stack nodes I want in different ranks within the same rank. As well, concentrate = true doesn't seem to work for edges between nodes within the same rank, as it leaves them as two separate curved edges ---> and o--- without concentrating them.
The reason why I need this to work is because I'm running model simulations where the edges change, and I need to generate hundreds of such graphs. For easy comparison, the nodes need to stay in the same place for consistency.
This is the closest I could come up with using neato format (nodes are positioned the way I want but it's not showing the proper o---> for all the black edges minus self-edges; red edges are true one-way links): https://i.stack.imgur.com/YJBY7.jpg
If only the edges showed up as the proper o---> format, this would be perfect for my needs. If you know of any way to fix this issue using DiagrammeR/GraphViz, or even another program, I would be so grateful. Thanks!
You probably don't need concentrate. Look at arrowtail and dir (https://www.graphviz.org/doc/info/attrs.html#d:arrowtail and https://www.graphviz.org/doc/info/attrs.html#d:dir) and neato -n
digraph c {
graph[label="can neato do the work?"]
node[shape=circle]
a [pos="100,100"]
b [pos="200,100"]
c [pos="300,100"]
a->b [dir=both arrowtail=odot]
c->c [dir=both arrowtail=odot arrowhead=none]
}
Giving:
Related
I want to write a program with 'geometry automata'. I'd like it to be a companion to a book on artistic designs. There will be different units, like the 'four petal unit' and 'six petal unit' shown below, and users and choose rulesets to draw unique patterns onto the units:
I don't know what the best data structure to use for this project is. I also don't know if similar things have been done and if so, using what packages or languages. I'm willing to learn anything.
All I know right now is 2D arrays to represent a grid of units. I'm also having trouble mathematically partitioning the 'subunits'. I can see myself just overlapping a bunch of unit circle formulas and shrinking the x/y domains (cartesian system). I can also see myself representing the curve from one unit to another (radians).
Any help would be appreciated.
Thanks!!
I can't guarantee that this is the most efficient solution, but it is a solution so should get you started.
It seems that a graph (vertices with edges) is a natural way to encode this grid. Each node has 4 or 6 neighbours (the number of neighbours matches the number of petals). Each node has 8 or 12 edges, two for each neighbour.
Each vertex has an (x,y) co-ordinate, for example the first row in in the left image, starting from the left is at location (1,0), the next node to its right is (3,0). The first node on the second row is (0,1). This can let you make sure they get plotted correctly, but otherwise the co-ordinate doesn't have much to do with it.
The trouble comes from having two different edges to each neighbour, each aligned with a different circle. You could identify them with the centres of their circles, or you could just call one "upper" and the other "lower".
This structure lets you follow edges easily, and can be stored sparsely if necessary in a hash set (keyed by co-ordinate), or linked list.
Data structure:
The vertices can naturally be stored as a 2-dimensional array (row, column), with the special characteristic that every second column has a horizontal offset.
Each vertex has a set of possible connections to those vertices to its right (upper-right, right, or lower right). The set of possible connections depends on the grid. Whether a connection should be displayed as a thin or a thick line can be represented as a single bit, so all possible connections for the vertex could be packed into a single byte (more compact than a boolean array). For your 4-petal variant, only 4 bits need storing; for the 6-petal variant you need to store 6 bits.
That means your data structure should be a 2-dimensional array of bytes.
Package:
Anything you like that allows drawing and mouse/touch interaction. Drawing the connections is pretty straightforward; you could either draw arcs with SVG or you could even use a set of PNG sprites for different connection bit-patterns (the sprites having partial transparency so as not to obscure other connections).
I'm working on a problem to eliminate common line segments in a collection of Paths. Many of these paths share the same segment.
It seems that a 2D line would have some way to uniquely identity itself. Like a Key.
So a Line [(A,B), (C,D)] is the same as [(C,D), (A,B)]
Only Solution I could come up with is to sort the points.
This seems like it would be a common problem in Math or Graphics but the solution escapes me.
From a mathematical point of view, this looks like a matter of an undirected graph (as opposed to a directed graph).
Sorting the points is one way to handle this: it's a straightforward way to represent an unordered edge with a single, unambiguously selected value (it shouldn't matter what ordering you choose, as long as it is consistent for all possible segments). You do need to ensure that you maintain this ordering as an invariant: accidentally slipping in a mis-ordered edge could cause problems for anything that depends on the ordering.
However, mathematically speaking, undirected graphs are often defined as directed graphs with a symmetry property: if (A,B) is an edge, then so is (B,A). This suggests another way: ensure that you always store both (A,B) and (B,A). Perhaps both segment orderings could have a link to any common data, and possibly a fast way to access one from the other. (As with the sorted point method, you need to maintain this symmetry as an invariant.)
The best choice depends on your application. If you're using your segments as a key, the sorting method might be best. However, some applications are a better match for the symmetric method. For example, the doubly connected edge list is a data structure which represents each edge as two linked "half-edges", one in each direction.
Since you mention graphics, note that the doubly connected edge list is often used to represent the edges of 3-D polytopes.
Also, note the similarity to oriented triangles: there are good, practical reasons for computer graphics to treat triangles as "one-sided", such that drawing a triangle visible from one side is distinct from drawing the same triangle visible from the other. Like half-edges, this distinction is determined by the order of the vertices: clockwise for one side, counterclockwise for the other.
Suppose I am greedily assigning colors to edges of a graph G = (V,E) as follows,
Select an uncolored edge (u,v)
Identify the colors of all edges touching u and select the lowest unused color. Do the same for v.
Assign (u,v) the larger of the two colors.
A trivial way to perform step 2 is to check all colors 1,2,... until coming across one that is not used by any edge touching u. Is there a faster way?
Just look at this. Depending on what yout exactly want, you can have variations of the algorithms that can have a performance boost, wether you're looking one or all solutions.
You can also go through all the edges connected to u, eliminating colors that are used, and then pick the first unused color.
Using iGraph, how can I represent self-reflexive nodes with circle shaped curves? By default, these curves are represented by a pinched or tear drop shaped loop.
As Spacedman said, you would need to do quite some programming to do this. You could plot a graph without self-loops and then add them (graphs are basically a scatterplot and you can use points and similar functions to add lines to them), but this is not trivial (especially since you need to know the edge of nodes, not their center) and will cause the selfloops to be plotted on top of everything else which might not look good.
This weekend I have updated qgraph with how self-loops work. qgraph can be used to plot networks and should play nicely with igraph. e.g.:
# An adjacency matrix:
A <- matrix(1,3,3)
library("igraph")
# igraph graph and layout:
Graph <- graph.adjacency(A)
Layout <- layout.circle(Graph)
# Plot in qgraph:
library("qgraph")
qgraph(get.adjacency(Graph,sparse=FALSE),layout=Layout,diag=TRUE,directed=TRUE)
I am quite content with how these self-loops turned out and they seem to be more to what you describe. So this could be an option. However, my loops are just as hardcoded. For reference, I compute the edge of a node (starting and ending point of the loop) with the inner function qgraph:::Cent2Edge and compute the shape of the loop (spline) with the inner function qgraph:::SelfLoop.
Inside plot.igraph you can see that loops are drawn using a plot.bezier function, and all the control for that is pretty much hard coded there. You'd have to rewrite large chunks of plot.igraph to call a plot.circle function you'd have to write to do this.
Also, I'm guessing you don't want complete circles, but circle segments that start on the edge of the vertex symbol (the default blue circle with the vertex number in it) and end (possibly with an arrowhead) on another part of the edge of the vertex symbol? Or do you want circles that touch the symbol like the bezier teardrop loops do?
Either way, the answer seems to be 'no, not without doing some programming or submitting a feature request to the igraph guys'
I posted an earlier answer saying the layout functions were involved, but that's not true - the layout functions only position the vertices, and it is plot.igraph's job to draw the edges.
I was wondering if someone could help with the following problem.
I have a dozen nodes, each a different sized circle between 0 - 10. I have a distance for each node-pair (e.g. node A and B are 6 from each other, etc.)
Given this data, would it be possible to compute the position of each node on a grid?
The distance could be from the centre or the edge of a node.
Thanks.
If you just want to have a graph to look at, try building a neato file where you specify edge distance. Neato is a layout program that is part of the GraphViz package.
This is quite easy. Your example above would look like this:
graph G {
A -- B [len=6]
}