-
Notifications
You must be signed in to change notification settings - Fork 1
Open
Description
Our printing of the MTG when we write back to disk takes too many columns e.g.:
^+A1
^/GU1
/N1
<N2
+A2
^/GU1
/N1
^<N2
<N3
<N4
<N5
<N6
<N7
^+Leaf1
^+Leaf1
^+Leaf1
^+Leaf1
^+Leaf1
^+Leaf1
<N3
<N4
0
^/GU1
/N1
^<N2
<N3
<N4
<N5
^+Leaf1
^+Leaf1
^+Leaf1
^+Leaf1
<N5
<N6
<N7
<N8
^+Leaf1
^+Leaf1
^+Leaf1
^+Leaf1
^+Leaf1
^+Leaf1
^+Leaf1
^+Leaf1
This one can be reduced to the following just by changing the rules that decide when we create new columns, and how we order the nodes:
^+A1
^/GU1
^/N1
+Leaf1
^<N2
+Leaf1
+A2
^/GU1
^/N1
^<N2
+Leaf1
^<N3
+Leaf1
^<N4
+Leaf1
^<N5
+Leaf1
^<N6
+Leaf1
^<N7
+Leaf1
^<N3
+Leaf1
^<N4
+Leaf1
+A2
^/GU1
^/N1
^<N2
+Leaf1
^<N3
+Leaf1
^<N4
+Leaf1
^<N5
+Leaf1
^<N5
+Leaf1
^<N6
+Leaf1
^<N7
+Leaf1
^<N8
+Leaf1
Check the rules, but I think that (rapid analysis):
- we shouldn't create a new column if the node has only one child;
- the nodes that follow should stay in the same column, and the nodes that branches should go in a new column, unless they have no siblings
- we should visit the branching nodes first, put them in a new column (unless they have no sibling has I just said), then the nodes that follow (and keep them in the same column as we can't have two nodes that follow I think);
- nodes that decompose should stay on the same column that their parents, unless they have siblings, in that case they should be in a new column (but first, before branching nodes)
Metadata
Metadata
Assignees
Labels
No labels