Puzzled over "List Item" component with tree as index input

This worked fine when I had a single list as "List" input, but now that I have two lists, the outcome is not what I expect :

I thought that the indexes from {0;0} and {0;1} would output items from the branch {0} of the list, and indexes from {1;0} and {1;1} would output items from the branch {1} of the list.

Is there an easy way to achieve this, or is it going to be path management hell ?

Replies to This Discussion

Permalink Reply by Petras Vestartas on August 21, 2017 at 4:29am

It is what happens when doing random stuff.

Seems like first branch is ok with first branch, while second branch is dealing with 0.1 1.0 1.1 branches.

I would duplicate fruits and names branches so that their tree would match indexing.

Permalink Reply by Olivier Suire on August 21, 2017 at 4:34am

Hi Petras,

Thanks for the patronizing comment.

I was expecting the "List Item" component to function in a useful way, that's all.

It is regretable that doing simple things with trees is often counter-intuitive and very tedious, such as the solution you are proposing.

Permalink Reply by Andrew Heumann on August 21, 2017 at 9:14am

branch indices have NOTHING, I repeat NOTHING to do with matching. YOUR BRANCH PATHS DO NOT MATTER. The exact same "longest list" matching process happens at the branch level first, and then at the item level. It just proceeds one by one through each branch, matching them up, and if it "runs out" it uses the last one repeatedly.

Permalink Reply by Olivier Suire on August 21, 2017 at 9:24am

Hi Andy,

I find it sad that no simple matching process is available.

The easiest way I can see here to solve my issue is to duplicate branches from my lists, as Petras suggested .

But since I may have any number of lists to process, the path mapper would be of no help because it is not dynamic.

If you have an elegant and simple way to deal with this, I would be happy to read it.

Regards,

Permalink Reply by Andrew Heumann on August 21, 2017 at 9:25am

Here are three ways to tackle this problem, with native components, tree sloth, or metahopper:

Permalink Reply by Olivier Suire on August 21, 2017 at 9:31am

Awesome,

Thanks Andy.

Permalink Reply by Andrew Heumann on August 21, 2017 at 9:40am

Incidentally, I don't mean to minimize your frustration: I totally understand the intuition that matching should somehow be able to "figure it out" based on the structure. However, data matching in Grasshopper operates this way for a reason: There actually is no foolproof, unambiguous way to solve certain kinds of matching scenarios on the basis of data tree structure alone. Imagine this scenario:

What is the "correct" solution here? Should Small match with Red? with Circle? with "1"?

The solution as currently implemented in GH has the advantage of being generally forgiving and flexible - you can match a tree that looks like {0;0}-{0;10} with one that looks like {0;0;0;0}-{0;0;10;0} (a common scenario).

The disadvantage is that extra manual work is required to be explicit about how matching should occur. Dave Stasiuk's tree sloth "propagate ancestors" is probably the closest to the matching behavior I think you and many others expect - where branch indices are matched explicitly, starting from the left - but this requires your paths to be managed very precisely (the example I gave above fails if you do not simplify the "A" input, for instance.)

I am sure David Rutten has many more reasons why this kind of "loose" count matching is preferred over explicit branch index propagation, but I can attest at least that if this were the default behavior for all components it would probably cause more problems than it solves.

Permalink Reply by Olivier Suire on August 21, 2017 at 3:05pm

Andy, thanks again for a great explanation.

What I don't like about the current state of affairs, is that definitions which work with one item as a base input will suddenly fail utterly when fed with a collection of items because suddenly, lists become trees.

At least, I finally got a good example of how to use "Unflatten" ; I guess I had discarded it a bit too fast as "one of those fancy and useless components".

Permalink Reply by Olivier Suire on August 22, 2017 at 8:20am

Now that my definition works for multiple inputs... it no longer works for a single input : tree structure becomes unfit.

I used the treesloth "Shift path safely", but that was not sufficient as the branching level was no longer suitable later on in the definition.

Therefor, for each place where this poses a problem, I need to add a stream filter :

This is terrible.

I am contemplating adding a "bogus" input to make sure there are always at least two objects as input upstream, which will make the tree structure consistent.

Then I just have to ignore the output for this bogus object at the end of the definition.

Permalink Reply by Andrew Heumann on August 22, 2017 at 8:54am

hmmm.. would love to see more context of the operation. I've written literally thousands of definitions and *never* had to do anything like that to handle different tree scenarios. One issue I see is that (in my opinion) the two operations that should always be avoided when crafting routines that work for arbitrary tree scenarios are Flatten and Simplify - because they operate on an absolute rather than relative basis.

Permalink Reply by Andrew Heumann on August 22, 2017 at 8:57am

for one, if you never simplify you never need to "shift paths safely" because there will always be a leading zero.

Permalink Reply by Olivier Suire on August 22, 2017 at 9:18am

Ah... leading zeros... Sometimes vertuous, sometimes a pain in the neck.