Comparing and grouping lists


I wish the following exemple had only 3 levels, but I couldn’t do it. My doubt is: is it possible to exam the list, and separate in 3 distinct groups (by list length) maintaining the objects indexes?

The actual list that I need to work is a list of walls, but I guess the logic is the same.

Captura de tela 2022-05-11 145220

Hi there,
Can you visually show us an example of the result you’d like to become?

I guess it is something like that:

Don’t know if it helps, but at L2, my lists will always have 2 item (even numbers), 1 item (odd number), or be empty.

hmmmmmm @rodrigo.bezerraRD5KM

Thanks for the insight, but it isn’t what I had in mind.

See, I’m testing if some geometries (a bunch of them) intercept another bunch of geometries. I to test another parameter of these first geometries, I need to know if they clash with 2, with 1, or with none other geometry. That’s why maintaining levels is kinda important: later on I’ll use the indexes to fetch family instances in the model.


Can you post a example … :wink: or start a new topic

(Image from @Draxl_Andreas)

The second output looks like the structure you asked for (plus the empty lists). You’ll have to be more specific about what you’re looking for if you need something else.

1 Like

I appreciate the help, guys… But you’re totally missing the point here. I don’t want just to get rid of a level of list. It was just me sucking at code block. That’s the actual list I’m working with:

What I need separate lists of sublists:

  • A list that have 2 items;
  • A lists that have 1 item;
  • There’s no no need for a list of empy lists, I realise now;

And would be great if the indices could be preserved somehow, so I can use them to pick items the item from the mother-list.

Or do you guys think it would be better if I test the number of clashes BEFORE this list I have and work them separately?

Edit: another image, with a little more context

What about List.Count as input as the Keys in a List.GroupByKey node? (Or a dictionary)

Gotcha. That makes more sense. As @Daan said, List.Count is the easiest way to filter the sublists but it won’t keep the empty indices without a little extra work. What are you going to do with the two lists once you’ve filtered them and will you be combining them back together? You could probably just keep the list intact and apply separate functions with an If node instead of filtering, but again we need more info.

Well, that’s a work in progress. Have you ever seen models where each wall layer is modeled as a distinct wall instead of modeling all layers of a compound wall? When you do that, the door and wall trims skip the non-host walls and the resulting drawing is a mess in magnification scales. I’m challenging myself to do a graph that tests the walls each door/window is supposed to cut, then feed a few parameters to adjust the geometry. I’m almost getting it, but I’m still struggling with knowing how many walls each door/window cut, to determine if some offset from the core centerline is needed, and if this offset is positive or negative value.

This is the work in progress:

So to me that sounds like the number of intersecting walls doesn’t really matter. You would do the same thing for a door cutting 1 wall as you would a door cutting 2 walls. You just need to handle summing of multiple walls.

I’m not quite sure if doesn’t matter. Please consider 2 distinct groups of aligned walls that sum 19cm width. One group could be 2.5+14+2.5cm and the moving parts of my family will have 0 offset from the core wall. The other could be 5+14cm and the moving parts will offset by 2.5cm to the external wall. So knowing how many walls are intersected might be important somehow. It’s something I’ll test tomorrow.

It could be. You’re right. But you might be able to avoid that depending on the logic you use. You still have to know which side of the host your walls are on in order to know whether you would add them together or subtract them from each other. Even then, you still need to know which side to move towards with the resultant value. My point here is that, based on that location, you can add or substract the intersecting wall values by defining a positive and negative side to the wall. Then it doesn’t matter how many walls there are. The ones on the positive side increase the offset and the ones on the negative side decrease the offset.

1 Like

WOW… That’s really good approach!!! I’ll surely explore it from now on.

1 Like

Glad to help. Two suggestions for when you get stuck on tricky problems like this:

  1. Work backwards. Start with the output you know you need and then work back towards each sequential input.
  2. Try to incorporate “generic” logic. Like in this case, rather than handling two or three conditions separately, see if you can define logic (even if it feels like more effort) that works for all cases at once.
1 Like