Your Opinion on Tree Simplification Rules

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:


RemoveLeadingOverlaps simplifies this to:


RemoveTrailingOverlaps simplifies this to:


and RemoveAllOverlaps (which is the default option) simplifies this to:


The problem comes in when a tree contains paths of varying length, for example:


How should the three options behave in your opinion?

My 2 cents in this specific case:




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.

\left. \begin{array}{} \{0;0\} \\ \{0;0\}\end{array} \right\} \text{not allowed}

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.

1 Like

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:


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”

It would be quite useful to have that built in to simplify as an option

Renumbering will be one of the options for all parameters, alongside but not part of simplify. Also alongside:

  1. Flatten
  2. Graft
  3. Sort
  4. Remove null
  5. Remove invalid
  6. Remove empty list
  7. Apply expression
  8. Collapse (aka shift path)
  9. Reverse

In the case of resulting duplicate paths after simplification, I would assume these to be merged into one path.

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.

A little late but 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.