;1},{0;2},{0;3}, (note that the first item is NOT {0,0})
{1;1}{1;2},{1;3},
{2;1},{2;2},{2;3},
{3;1}{3;2},{3;3}...
Well I'll just upload an extract of the definition. The data path should be the same, but with the items in the last path shifted to the first path, and the items in the first path shifted to the second path and so on.
I'll keep trying. …
lengths, with a set of possible algorithms to perform the matching.
Stream 1: {0;0;0} {0;0;1} {0;1;0} {0;1;1} {0;1;2}
Stream 2: {0;0} {0;1}
"trim end" and "trim start" matching could be applied between the paths - applying either an {A;B;C} -> {A;B} mapping to stream one, or {A;B;C} -> {A;B}.
In a more complex situation:
Stream 1: {0;0;0} {0;0;1} {0;1;0} {0;1;1} {0;2;0} {0;2;1}{0;2;2}{0;2;3}
Stream 2: {0} {1} {2}
Stream 3: {0;0;0;0} {0;0;1;0}{0;0;1;1} {0;0;1;2} {0;0;2;0}
This could conceivably include all kinds of ambiguous cases, but here's a stab at an algorithm that might sort them appropriately most of the time:
Find the highest value for each path index in each stream - so 1 has {0;2;3}, 2 has {2} and 3 has {0;0;2;2}
Find the shortest path length N across all paths - in this case N=1
find the highest (leftmost) shared pattern of N sequential values across all paths (here just {2})
Simplify all streams to the matching set of indices. (Stream 1: {A;B;C} -> {B}, Stream 2 {A} -> {A}, Stream 3: {A;B;C;D} -> {C})
Not sure if this makes sense - (either because I've explained it poorly or because the idea itself is bad.) But hopefully at least the goal is clear - to find a most-of-the-time routine to reconcile paths of different lengths according to their overlap. …
ems in the same way. Lofting was particularly difficult, you had to have a separate loft component for every lofted surface that you wanted to generate because the component would/could only see one large list of inputs. Then came along the data structures in GH v0.6 which allowed for the segregation of multiple input sets.
If you go to Section 8: The Garden of Forking Paths of the Grasshopper Primer 2nd Edition you will find the image above describing the storing of data.
Here you will notice a similarity between the path {0;0;0;0}(N=6) and the pathmapper Mask {A;B;C;D}(i). A is a placeholder for all of the first Branch structures (in this case just 0). B is a place holder for all the second branch structures possibly either 0, 1 or 2 in this case. And so forth.
(i) is a place holder for the index of N. If you think of it like a for loop the i plays the same role. For the example {A;B;C;D}(i) --> {i\3}
{0;0;0;0}(0) --> {0\3} = {0}
{0;0;0;0}(1) --> {1\3} = {0}
{0;0;0;0}(2) --> {2\3} = {0}
{0;0;0;0}(3) --> {3\3} = {1}
{0;0;0;0}(4) --> {4\3} = {1}
{0;0;0;0}(5) --> {5\3} = {1}
{0;0;0;1}(0) --> {0\3} = {0}
{0;0;0;1}(1) --> {1\3} = {0}
{0;0;0;1}(2) --> {2\3} = {0}
{0;0;0;1}(3) --> {3\3} = {1}
{0;0;0;1}(4) --> {4\3} = {1}
{0;0;0;1}(5) --> {5\3} = {1}
{0;0;0;1}(6) --> {6\3} = {2}
{0;0;0;1}(7) --> {7\3} = {2}
{0;0;0;1}(8) --> {8\3} = {2}
...
{0;2;1;1}(8) --> {8\3} = {2}
I'm not entirely sure why you want to do this particular exercise but it goes some way towards describing the process.
The reason for the tidy up: every time the data stream passes through a component that influences the path structure it adds a branch. This can get very unwieldy if you let it go to far. some times I've ended up with structures like {0;0;1;0;0;0;3;0;0;0;14}(N=1) and by remapping the structure to {A;B;C} you get {0;0;1}(N=15) and is much neater to deal with.
If you ever need to see what the structure is there is a component called Param Viewer on the first Tab Param>Special Icon is a tree. It has two modes text and visual double click to switch between the two.
Have a look at this example of three scenarios in three situations to see how the data structure changes depending on what components are doing.
…
o three parts:
branch 1:
{0;0} N = 3
{0;1} N = 3
branch 2:
{1;0} N = 5
{1;1} N = 5
branch 3:
{2;0} N = 30
{2;1} N = 30
parthmapper won't change the length of branch, explode tree won't give me two branches in one output
…