I have following tree:
digraph G {
subgraph cluster0{
37[label="+"];
42[label="a"];
44[label="b"];
47[label="*"];
46[label="c"];
49[label="d"];
51[label="e"];
53[label="f"];
55[label="g"];
57[label="h"];
61[label="*"];
60[label="i"];
63[label="j"];
37 -> 42[label="c"];
37 -> 44[label="c"];
37 -> 47[label="c"];
37 -> 61[label="c"];
42 -> 37[label="p"];
44 -> 37[label="p"];
47 -> 37[label="p"];
47 -> 46[label="c"];
47 -> 49[label="c"];
47 -> 51[label="c"];
47 -> 53[label="c"];
47 -> 55[label="c"];
47 -> 57[label="c"];
46 -> 47[label="p"];
49 -> 47[label="p"];
51 -> 47[label="p"];
53 -> 47[label="p"];
55 -> 47[label="p"];
57 -> 47[label="p"];
61 -> 37[label="p"];
61 -> 60[label="c"];
61 -> 63[label="c"];
60 -> 61[label="p"];
63 -> 61[label="p"];
}
}
Output is here: http://i.imgur.com/q1qXkCT.png
Order of children in first * subtree is: G H C D E F, but it should be C D E F G H.
I have noticed that if I delete subgraph cluster0{ the order is right, but I can't do it this way.
Can you suggest any other solution?
Graphviz attempts to retain the lexical ordering of nodes when there is no other constraint. However, the edge labels can affect placement as they take up space and can push nodes around.
If you have a specific order that is essential, then try something like
{ rank = same;
46 -> 49 -> 51 -> 53 -> 55 -> 57 [style = invis];
}
to introduce the additional ordering constraint into the graph.
You need to be careful with this though, as it can distort more complex graphs in ways that are very difficult to predict.
Clusters further complicate matters in larger graphs as they implicitly attempt to make the subgraph more compact and introduce a bounding box that non-cluster members cannot cross.
Related
Is it possible to collapse multiple paths like shown in the picture with graphviz? And if so any suggestions on how this could be achieved?
I'm used to the weeds.
Comment out unwanted nodes and edges and add 3 nodes with shape=point. You might also create invisible edges to/from the new nodes, I did not.
This:
digraph ellipsis {
rankdir=RL
nodesep=.1
node [shape=circle]
{
rank=same
B1
B2
B3
/* comment out unwanted nodes
B4
B5
...
*/
e4 [shape=point]
e5 [shape=point]
e6 [shape=point]
B99
edge [style=invis]
B1 -> B2 -> B3 -> e4 -> e5 -> e6 -> B99
}
C -> B1
C -> B2
C -> B3
/* comment out unwanted edges
C -> B4
*/
C -> B99
B1 -> A
B2 -> A
B3 -> A
/* comment out more unwanted edges
B4 -> A
*/
B99 -> A
}
Produces this:
I'm trying to align this graph, whose purpose is to show the results of sorting.
I need a general solution.
The dot file is generated, so I can't use hand tweaking.
I've tried pos, pos with !, dot -n, dot -Kneato, dot -Kfdp, and other things.
Here is the source (laid out for human grokkability):
digraph x {
rankdir=LR
11 [pos="1,1"] 21 [pos="2,1"] 31 [pos="3,1"] 41 [pos="4,1"]
12 [pos="1,2"] 22 [pos="2,2"] 32 [pos="3,2"] 42 [pos="4,2"]
13 [pos="1,3"] 23 [pos="2,3"] 33 [pos="3,3"]
14 [pos="1,4"] 24 [pos="2,4"]
11:e -> 21:w 21:e -> 31:w 31:e -> 41:w
12:e -> 22:w 22:e -> 32:w 32:e -> 42:w
22:e -> 31:w
# 41:e -> 21:w
# 41:e -> 22:w
# 12:e -> 12:w
# 32:e -> 32:w
13:e -> 23:w 23:e -> 33:w
14:e -> 24:w
# 13:e -> 14:w
# 14:e -> 13:w
# 23:e -> 24:w
# 24:e -> 23:w
}
In the first rendering, you'll see essentially how it should look (except for the shuffled row order).
Later renderings, which will include cyclic edges, should retain this basic layout.
dot -Tpng -o test.png test.dot:
Now some renderings after uncommenting the cyclic edges.
dot -Tpng -o test.png test.dot:
dot -Kneato -Tpng -o test.png test.dot:
dot -Kfdp -Tpng -o test.png test.dot:
Not using pos as in my experience (confirmed by your attempts), it does not work well with the dot engine, and with neato and others I have never been able to produce something like a grid layout.
Three general steps to get closer with dot:
align the nodes vertically with rank = same
align the nodes horizontally using weight = 10 (or any other arbitrary number that works)
add invisible vertical struts as necessary (here 14 -> 12)
make sure that you point the edges following the established hierarchy, meaning explicitly using dir = back where appropriate
My shot at your situation:
digraph
{
rankdir = LR;
{rank = same; 14 -> 13 -> 12 -> 11[ style = invis ] }
{rank = same; 24 -> 23 -> 22 -> 21[ style = invis ] }
{rank = same; 33 -> 32 -> 31[ style = invis ] }
{rank = same; 42 -> 41[ style = invis ] }
14 -> 24[ weight = 10 ];
13 -> 23 -> 33[ weight = 10 ];
12 -> 22 -> 32 -> 42[ weight = 10 ];
11 -> 21 -> 31 -> 41[ weight = 10 ];
22:e -> 31:w;
12:e -> 12:w
32:e -> 32:w
21:se -> 41:sw[ dir = back ];
22:se -> 41:sw[ dir = back ];
14 -> 12 [ color = red ];
14:w -> 13:w
13:e -> 14:e[ dir = back ];
24:w -> 23:w
23:e -> 24:e[ dir = back ];
}
which yields
There are four dot files (cluster_0, cluster_1, cluster_2, cluster_3) which need to be merged into a single dot file.
The code of the individual dot files is as follows.
digraph cluster_0{
sortv=1;
penwidth=0;pencolor=transparent;
label="1A";
rankdir=LR;
node [fontname = "times-roman-bold",fontsize=12];
edge [fontname = "times-roman-bold",fontsize=12,arrowsize=0.75];
1 [label="1:A"];
2 [label="2:C"];
3 [label="3:G"];
3 -> 1
1 -> 2
3 -> 2
2 -> 3
}
digraph cluster_1 {
sortv=2;
penwidth=0;pencolor=transparent;
label="1B";
node [fontname = "times-roman-bold",fontsize=12];
edge [fontname = "times-roman-bold",fontsize=12,arrowsize=0.75];
rankdir=LR;
11 [label="1:A"];
12 [label="2:C"];
13 [label="3:G"];
14 [label="4:T"];
14 -> 11
11 -> 12
12 -> 13
12 -> 14
13 -> 14
}
digraph cluster_2 {
rankdir=LR;
sortv=3;
penwidth=0;pencolor=transparent;
label="1C";
node [fontname = "times-roman-bold",fontsize=12];
edge [fontname = "times-roman-bold",fontsize=12,arrowsize=0.75];
21 [label="1:A"];
22 [label="2:C"];
23 [label="3:G"];
24 [label="4:T"];
25 [label="5:A"];
24 -> 21
21 -> 22
21 -> 25
25 -> 22
22 -> 23
23 -> 24
}
digraph cluster_3{
sortv=4;
penwidth=0;pencolor=transparent;
label="1D"
node [fontname = "times-roman-bold",fontsize=12];
edge [fontname = "times-roman-bold",fontsize=12,arrowsize=0.75];
rankdir=LR;
31 [label="1:A"];
32 [label="2:C"];
33 [label="3:G"];
31:c -> 31:w
32 -> 31 [dir=both,len=1.25];
33 -> 31 [dir=both,];
32 -> 32
33 -> 32 [dir=both,];
33 -> 33
}
To generate a merged single dot file ...I ran the following command.
neato -Gstart=5 cluster_0.dot cluster_1.dot cluster_2.dot cluster_3.dot | gvpack -array_u4 | neato -n2 -s -Teps -o merge.eps
merge.eps came perfectly well but the labels of the individual graphs went missing. How can we preserve the labels of the individual graphs in the output merge file ? Can anyone help to fix this ?
Here I am attaching the single individual file where the label is shown
I compiled the individual file with the following command.
neato -Gstart=5 cluster_0.dot -Teps -o cluster_0.eps
Also I am attaching the merge output file which removed the labels of the graphs.
This is not an answer but rather sharing experiences: As it turns out while experimenting with various options, it seems to be the neato engine that supresses the labels. If you use dot, you may not get the exact layout you want but you get the labels:
dot -Gstart=5 cluster_0.dot cluster_1.dot cluster_2.dot cluster_3.dot | gvpack -array_u4 | dot -n2 -s -T jpg -o merge.jpg
gives you
My personal preference would by to have one master file so.m4
digraph so
{
define(`digraph',`subgraph')
rankdir=LR;
include(cluster_0.dot)
include(cluster_1.dot)
include(cluster_2.dot)
include(cluster_3.dot)
}
that I process with
m4 so.m4 > so.dot
In the resulting so.dot file, I have all clusters combined, and I can go to the next step (here producing a JPG) with a simple
dot -T png -o so.png so.dot
The advantage of that is that you can use the master file for "global options". I think it is easier to maintain and less unwieldy than the command with all the pipes and options. But that's a matter of taste.
With the option rankdir=LR; this version is produced:
Have fun - happy to do more but I'd need to know more about your project.
I'm using graphviz (dot) to generate time expanded graph to use in my master thesis. However, my drawing results the following graph:
As you can see, the third line is a little bit shifted to the right.I want all the lines in the same horizontal line. Also i want the x.th node in each line to stay at the same horizontal line of other x.th nodes of lines. Changing the edge weights would not helped me.
I could not find anything related to this problem so far.
What i want to achieve is something like this:
Here is my code:
digraph G {
1[label="1"]
2[label="1"]
3[label="1"]
4[label="1"]
5[label="1"]
6[label="1"]
7[label="2"]
8[label="2"]
9[label="2"]
10[label="2"]
11[label="2"]
12[label="2"]
13[label="3"]
14[label="3"]
15[label="3"]
16[label="3"]
17[label="3"]
18[label="3"]
19[label="4"]
20[label="4"]
21[label="4"]
22[label="4"]
23[label="4"]
24[label="4"]
rankdir="LR";
node[width=0.15, height=0.15, shape=point];
edge[weight=500, label="1"];
1 -> 2 -> 3 -> 4 -> 5 -> 6 ;
7 -> 8 -> 9 -> 10 -> 11 -> 12 ;
13 -> 14 -> 15 -> 16 -> 17 -> 18 ;
19 -> 20 -> 21 -> 22 -> 23 -> 24 ;
edge[weight=3];
1 -> 9;
2 -> 9;
3 -> 11;
13 -> 22;
14 -> 22;
15 -> 24;
edge[weight=1];
1 -> 14;
2 -> 15;
3 -> 17;
7 -> 21;
8 -> 23;
9 -> 22;
}
Any help would be appreciated.
Instead of using weight try using the attribute constraint=false for all edges which go from one "line" to another.
Setting constraint to false makes graphviz to not consider those edges when laying out the nodes of the graph.
See also this very similar question & answer
As far as I know, the only way is to specify an explicit position for each individual node.
See: How to force node position (x and y) in graphviz
I make lot of dealing with RFID cards. As much as there are different readers there are different outputs and coding of same type of cards.
I got frequent request to figure out (if possible) to translate one output to another and that means that I have to stare at these numbers and figure out what transformations are.
Most common transforms are
added constant
reversed binary sequence
cutting a few bits away
rotation
combinations of this methods
I usually have something like 30% success rate, but I always got frustrated when after a few hours I can not find translation. It's probably very simple but I just can not figure it out. That is why I am looking for a kind of algorithm/library/software that would check these rules automatically on two sets of numbers and try to figure out smallest Kolmogorov complexity.
Since I have zero knowledge about data mining I would be thankful for any pointers.
This seems like a genetic programming problem.
The 'genes' are the individual bit transformations that can occur. The fitness function is how many bits are correctly transformed for growing input sets. A genetic programming library can shuffle genes around trying to find better fitness, and "breeding" the indivduals who have high fitness levels to attempt to create a more fit individual.
Check out pyEvolve .
I don't know what's the length of the numbers but let's assume they are 64-bit. The number of different non-trivial atomic transformations is then as follows
Added constant 2**64 - 1
Reversal 1
Remove bits 63
Rotation 63
If you have combinations also, you have 4 + 12 + 24 + 24 = 64 different ways to order a subset of the transformations (without taking the parameters of the transformation into account). So what I would do is to
Have an outer loop that iterates over the 64 ways to combine the transformations
Then have an inner loop that iterates over the maximum 63 * 63 parameter values for "remove bits" and rotation; now the total number of iterations is ~~ 643 == (26)3 = 218 which is okay
Apply the hypothetical transformation (one out of 218), and then calculate the differences between the first data set and the second data set transformed; if the difference is constant you have found the additive constant for the "added constant" transformation and are done
This should be very fast on a modern PC, i.e. you should be able to find the solution in a couple of seconds. If the data sets are large (> 100) you can use a sample first and then validate the result on the whole data set only when the subset works out correctly.
I wrote a small prove of concept. Here is what I have done.
I generated ten random binary strings with 64 digits as card content examples produced by a reference reader.
0010110111011011100000010001100011111001010100111101110111000100
0000000110001111101110001011110100000100111101100100110010100000
1111000010100111011000111000100111111001000010100101011100011001
0010011011100011001000010111100010110001001000010101001110000000
1111000100101100010011101011010011100111000000001111110010101110
0101011101000101110111000010100110000111001010000010000001110111
0101110010011010011110011110111100111001110010100111101001111101
0101110100100101110000101000001000011100010100010010110000010001
0111101011011010111001011011110101011100111011010111100110100101
0000101001000110111101000100111011110000000011010110001110101011
Then I generated a random mapping table to simulate the different output of another reader for the same ten cards. It has the format i -> j meaning bit i from the reference content occurs as bit j on the other reader.
4 -> 0 4 -> 1 49 -> 2 32 -> 3 51 -> 4 52 -> 5 10 -> 6 47 -> 7
16 -> 8 32 -> 9 14 -> 10 24 -> 11 13 -> 12 1 -> 13 8 -> 14 47 -> 15
12 -> 16 56 -> 17 55 -> 18 22 -> 19 6 -> 20 33 -> 21 22 -> 22 45 -> 23
37 -> 24 39 -> 25 46 -> 26 47 -> 27 25 -> 28 15 -> 29 43 -> 30 13 -> 31
33 -> 32 31 -> 33 16 -> 34 49 -> 35 0 -> 36 30 -> 37 28 -> 38 31 -> 39
45 -> 40 28 -> 41 17 -> 42 18 -> 43 40 -> 44 18 -> 45 23 -> 46 54 -> 47
11 -> 48 54 -> 49 41 -> 50 39 -> 51 28 -> 52 31 -> 53 1 -> 54 34 -> 55
45 -> 56 4 -> 57 59 -> 58 11 -> 59 6 -> 60 26 -> 61 21 -> 62 0 -> 63
52 -> 64 1 -> 65 55 -> 66 46 -> 67 49 -> 68 23 -> 69 47 -> 70 45 -> 71
28 -> 72 23 -> 73 41 -> 74 41 -> 75 16 -> 76 4 -> 77 4 -> 78 18 -> 79
For example bits one and two of the other readers output equal bit four of the reference reader output. The simulated output is 80 bits width and there are some bits duplicated and maybe some others missing.
11111101111000111110010001110110101100100100001010111001010100001011111011111110
00100100101110101100000110100111011100111101110000101100100001001001100110111001
00111010011111100011011001100101110110110111011101011111001000010111110011000001
00111011011000110110100001011100000100100101011101011001000011000010111011000001
00111110010111001101011011000001100110000010000000010011000001111100100000000000
00010000110011000000100011000101011000110110000000011110001011100100000010001000
11101100001101101000000001101000010101110111111111111111011101001101110011110111
11000111100111010001001010010111001001000010000000100010011000001100001000111110
11101101101101111110110110010000111100111111111010101110110111101110111111111111
11110001111010010110110100011001101101101111010101001001110010100010101110001111
Now we want to find the mapping between both data sets. For this we just look at the correlation between the bits. That means for each combination of a bit index i (0 to 63) produced by the reference reader and each bit index j (0 to 79) produced by the other reader we just count how many examples have matching bits at this positions.
111111111122222222223333333333444444444455555555566666
0123456789012345678901234567890123456789012345678901234567890123
0 3545.65456386363765535465634568436588433683666585575745656555647
1 3545.65456386363765535465634568436588433683666585575745656555647
2 4474534385457494458444376567873567875326554355654.48656783626534
3 64743565476336564544465525456333.7853368114353456646256765446574
4 669655438567727425624459656765356787734855435365684.656765446734
5 4656752763479454654464558367475525457744794735656666.72365644734
6 8676354543.33636254244956545235365655566334533456446476543266354
7 33638674585643657453154636365462565864334656463.5555545874333445
8 2434756747255656.54646334345655545255742576757474462652565642556
9 64743565476336564544465525456333.7853368114353456646256765446574
10 33636452963663.5549533285656964656786215665466763937547874535425
11 685853256165765447646475.365475725457744774555634666874343666536
12 6636334723613.36674666716343455565433764334555434462474343666376
13 6.5.554543655634494466758363455745457766554373434486654325686758
14 44745543.5477296438442396567853745677326776555854828656765444514
15 33638674585643657453154636365462565864334656463.5555545874333445
16 556564367438.363545575467478584636546655885646747757963476735843
17 42725365674574746364463545696733676535445565374768466547.3604552
18 5383647278564385547315483636744478786235445466585737347.74335445
19 9767443632944725363355.47434146456546675443644547355585434377465
20 445455.349453454656648352765655565453564538377274464216765644576
21 758562545656656356533766543656447.766455443466567757565874537665
22 9767443632944725363355.47434146456546675443644547355585434377465
23 534362745636656374775744565658663634465186766.565553545674735465
24 5747445834546725763577627276364634124.73667646345373761254753665
25 667637456565545625446457456563358585536.334351636648456547466754
26 6454552583477476436662576545655745657346774755.36626676547466534
27 33638674585643657453154636365462565864334656463.5555545874333445
28 5343667256564363347755463.54568454764255645466565555329656557465
29 445437476563365.634442554345613563455546356733654424474545262334
30 5343663854566547723553645436346434346653685.26767333783456353443
31 6636334723613.36674666716343455565433764334555434462474343666376
32 758562545656656356533766543656447.766455443466567757565874537665
33 5747445474366565567775467474764.34346655867486723555545436775647
34 2434756747255656.54646334345655545255742576757474462652565642556
35 4474534385457494458444376567873567875326554355654.48656783626534
36 .676334543855634254466956545255567635586534555638446476545468574
37 552586543456454356575564583236.434566453663666565373547436577467
38 2454556387255496658644174565.53765675326556375652846436765644536
39 5747445474366565567775467474764.34346655867486723555545436775647
40 534362745636656374775744565658663634465186766.565553545674735465
41 2454556387255496658644174565.53765675326556375652846436765644536
42 59496454345447435.5557647452566656566655443284343595545434777669
43 445453618545549445.644376765875745675324756377652846438763646336
44 5545645474388363547775467676586814346653.87668745555745456755645
45 445453618545549445.644376765875745675324756377652846438763646336
46 55856652965861853473334.5656744656788237665464765739547856355625
47 645455616565347425864457494365756587514653437565464623.745468356
48 55658654763.8163545555485656566636568455885666767557745658555845
49 645455616565347425864457494365756587514653437565464623.745468356
50 35458636743883657455534674565666143686338.5846765555963456553625
51 667637456565545625446457456563358585536.334351636648456547466754
52 2454556387255496658644174565.53765675326556375652846436765644536
53 5747445474366565567775467474764.34346655867486723555545436775647
54 6.5.554543655634494466758363455745457766554373434486654325686758
55 6474554365655474256444574745655387.75148332353656848458765448554
56 534362745636656374775744565658663634465186766.565553545674735465
57 3545.65456386363765535465634568436588433683666585575745656555647
58 68385745436536364746647565414377434575665545736342644563074.6558
59 55658654763.8163545555485656566636568455885666767557745658555845
60 445455.349453454656648352765655565453564538377274464216765644576
61 46563565654574544566863565.7673743433766758355434666634365844754
62 665653852745563267466.534565475567433784536377256484434565846796
63 .676334543855634254466956545255567635586534555638446476545468574
64 4656752763479454654464558367475525457744794735656666.72365644734
65 6.5.554543655634494466758363455745457766554373434486654325686758
66 5383647278564385547315483636744478786235445466585737347.74335445
67 6454552583477476436662576545655745657346774755.36626676547466534
68 4474534385457494458444376567873567875326554355654.48656783626534
69 55856652965861853473334.5656744656788237665464765739547856355625
70 33638674585643657453154636365462565864334656463.5555545874333445
71 534362745636656374775744565658663634465186766.565553545674735465
72 2454556387255496658644174565.53765675326556375652846436765644536
73 55856652965861853473334.5656744656788237665464765739547856355625
74 35458636743883657455534674565666143686338.5846765555963456553625
75 35458636743883657455534674565666143686338.5846765555963456553625
76 2434756747255656.54646334345655545255742576757474462652565642556
77 3545.65456386363765535465634568436588433683666585575745656555647
78 3545.65456386363765535465634568436588433683666585575745656555647
79 445453618545549445.644376765875745675324756377652846438763646336
Above are the results from this with a dot representing ten matches. As you can see this recovers the mapping for all bits except bits 13, 54, and 65 where two possible matches are found.
77 out of 80 bits with only ten samples is quite good. Admittedly this will not work that good if the bit patterns contain structure and are not just random bits or if you have to take bits computed from several bits into account. But if you have access to large enough sample sets you can uncover all possible mappings.