Request for input. Tree simplification in GH2 behaves differently from GH1 (even differently from Suirify).
There are three options for simplification; RemoveLeadingOverlaps, RemoveTrailingOverlaps, and RemoveAllOverlaps. In case this isn’t self-documenting, consider the following tree:
\{0;0;0;1;0\} \{0;3;0;2;0\} \{0;8;0;3;0\}
RemoveLeadingOverlaps simplifies this to:
\{0;0;1;0\} \{3;0;2;0\} \{8;0;3;0\}
RemoveTrailingOverlaps simplifies this to:
\{0;0;0;1\} \{0;3;0;2\} \{0;8;0;3\}
and RemoveAllOverlaps (which is the default option) simplifies this to:
\{0;1\} \{3;2\} \{8;3\}
The problem comes in when a tree contains paths of varying length, for example:
\{0;0\} \{0;0;0\} \{0;1;0\} \{0;2;0\}
How should the three options behave in your opinion?
So in this case you’d expect the first two lists to be merged into a single one? Note that a tree may not contain more than a single instance of a particular path.
Maybe if all the trees had always the same amount of paths it would eliminate the need to have varying paths of length. If you merge inputs with different paths, it should add an additional path to the one (or several) that are smaller.
Interesting idea, varying path lengths is almost always a sign of something amiss anyway.
However adding zeroes to a unique path in a tree might make it non-unique (the example in this discussion is one of those cases), what padding algorithm do you propose?
This might cause trouble with definitions which rely on calling very specific paths for matching down stream if you have paths changing like that with padding. Also this case:
{0;0}
{0;0;0}
would be stuck either way, if you pad it first you will get the same duplicate address issue.
While on the subject, another option for simplifying (not a replacement of what you suggested but potentially a 4th option) is “readdressing” which is something I find myself doing often. Tree Sloth has a component for it called “Renumber Paths”
But the whole point of Simplify is (and should be) that it doesn’t mess with the topology of the tree. It should only remove those path elements that don’t matter anyway.
I agree with Wim and Luis. I also would expect the result to be merged. Maybe it isn’t elegant but you could add a boolean toggle to merge the paths or to fail with trees of varying path lengths.
I think I’d have to side w/ DR on this one: that ‘Simplify’ should be restricted to its essential actions. (no thought on which way --seems that a user variable could be useful here?).
I’m just an average user. My GH def’s are not always scripted w/ the best hygiene, esp when they get large, include many objects, and are works-in-progress or sketches. Preventing unexpected behavior as much as possible should be paramount. It’s already difficult to track down items in the panel to see what went awry. Merging two branches because they’re “similar” 0;0 & 0;0;0 when all one wishes to do is simplify (better legibility?) would be breaking the underlying 0;1;2;3… branch order, and would create greater confusion (at least for me).
Perhaps including a flag for these instances (data tree has branches of diff lengths) could also help.