You know… 
… if path indexing started at 1, and extraneous zeros were added still added as zeros this all wouldn’t be a problem.
I think it might be getting late for both of us, this one does not quite add up. Let us sleep on it and pick it up another day
I attached a very simple example
unnamed.gh (18.3 KB)
As you can see, in the end i needed to get all my points connected by the polyline. Two different results, the only difference being in the top case one line is used instead of three.
And it can happen to subbranches too, not only to main branch.
One day I found myself in such scenario in a huge algorithm, and i had to go to the very beginning and replace all simplify. I never use it since then.
Volker mentioned that trim tree also gets rid of some information:
and he has the point, but as of right now, i do not remember myself braking anything with trim tree approach
Its a fine method, but again, it fixes the problem only for simple problem like this, not for subbranches, as the flatten you used would ruin the data structure. And again, the problem could be completely avoided just using trim tree 
If the datatree is more complex, the result of Trim Tree would not be an empty/null orange stream.
This problem occurs to me only when i’m expecting a complex datatree but in reality the data come as like as the starting flow is a lone geometry.
It’s just a matter of a specific datatree problem, i guess anyone of us here manage to solve it case by case.
Anyway, we are discussing “fired air” here… and OT.
I would say it works, but it is a classic example of bulldozing the house to rearrange the furniture. In general, as long as it works and people are happy with the results, that is fine, but it is an approximate and not fully conscious approach. This is what I mean when I say that tools like Simplify and Suirify are counterproductive: they let you skip the understanding and still get a result, which over time means unlearning rather than learning
I’m pretty confident nowaday I personally manage most complex scenarios, fully understanding what’s going on in a datatree… but I can be wrong and I always want to learn new stuff!
At the cost of going further OT, can someone post a practical example where Suirify does the job while other solutions are “impossible” or way more complex without it?
Yes, please!
I’m not a huge fan of simplify as I tend to build up stuff that can handle variable tree structure, i.e. if it works with 0;1 it should work with 0;2;0;1 as well without messing things up. Ideally whatever comes out of a this also keeps the same tree structure. Simply (and worse flatten 
) don’t do that.
Yes, you would not get an empty branch, but the trim would trim one level deeper than you want it too. So the result would be incorrect
The fundamental problem with simplify - if you used graft before it on a single branch, it completely ignores it, but does not ignore it with multiple branches.
So you get different depths of data structure, unintentionally and without control. And often you can not predict when this will happen.
Of course it adds up. What about it doesn’t make sense?
You’re probably familiar with how certain components output a -1 as a sentinel value, like Item Index, for example:
Same idea, just with different stripes for paths. If an added zero is hierarchically extraneous, use a -1 instead of a 0. This way, what is a procedural artifact can be distinguished from what is hierarchically significant. Simplify could then appropriately target the -1s without the danger of collapsing meaningful zeros.
In the above, I suggested starting counting from one and using zeros instead of -1, but it is the same idea.
Yes, but the problem remains, you have just shifted the numbering from 0,n to 1,n+1. How would you automatically distinguish a level that is needed from one that is not in order to assign it a 0?
- A Divide Curve with {1} containing curves 1, 2, 3 would generate
- {1;1}(points)
- {1;2}(points)
- {1;3}(points)
- A Divide Curve with {1} containing just one curve would generate
- {1;1}(points)
So what then? The structure is the same regardless of whether the extra level is meaningful or redundant. You cannot tell the difference automatically, which is exactly why it has to be a conscious decision by the user, and why I am talking about Ungraft/Stunt.
This is determined by the component. It knows how many extra integers it must add, as it is constant value. It can evaluate the input given to it against output it will produce, and either create 0 or -1. The structure is different because -1 != 0. To locally ungraft/stunt a -1 remains a decision by the user, but in a way becomes meaningless.
I have some doubts about this. It seems unintuitive and could break structures.
Take the previous example: a tree with
- {0} containing curves 0, 1, 2
- {1} containing curves 0, 1
After Divide Curve it becomes
- {0;0}(points)
- {0;1}(points)
- {0;2}(points)
- {1;0}(points)
- {1;1}(points)
Now imagine another tree arriving in parallel
- {2} containing curve 0
- {3} containing curve 0
After Divide Curve, with your logic, this would become
- {2;-1}(points)
- {3;-1}(points)
If you then merge them you get
- {0;0}(points)
- {0;1}(points)
- {0;2}(points)
- {1;0}(points)
- {1;1}(points)
- {2;-1}(points)
- {3;-1}(points)
Keep in mind that on the opposite side, we do not necessarily want to clean the last level every single time either. If you cut the -1 level before merging, the final tree doesn’t make sense; If you don’t cut it it doesn’t make sense either: each list {n;m} is the points of the (m+1)-th curve of the (n+1)-th list. So {3;-1} would be the points of the 0th curve of the fourth list? What does that even mean?
Also: you lose possibility to flip the matrix
We’re circling the drain. “Ungraft” is a good idea, although I don’t think it should be limited to a constant -1. The Youtrack David made: RH-51526 does not adress Ungraft specifically, but the ability to add modifiers to relays. It’s doubtful we’re going to see developers make any efforts to add ungraft as an option.
That was related to the original linked post (or at least the first time I saw this topic come up), where the core idea was good but still rough. Applied to relays specifically, it does not make much sense.
If the proposal is now more structured and solid (I hope so), and if it gets more traction and is not just my own wish, maybe there is more hope this time
Ok, we have at least a couple of positive answers and likes to the post, so now how do we reach the Devs?
I do not think its big enough to change it. And i do not think it would be backward compatible. They have so much stuff to work on that would be literally the last thing