Is list@L1 equal to flattened list?

According to

, list@L1 contains a flattened list.

But in my case, 2 3 , they’re different.

I think it relates to both lacing and the default level the list is working at. Hard to properly troubleshoot without seeing the element inputs also. I believe by default the parameter setting node will work to shortest lacing.

I was helping a colleague with lacing/levels and was going to put together a diagram for him to help further. Two birds one stone I figure;

example%201 example%202


[1,5] w/ or w/o flatten does the same thing. 1 and 5 applied to both [1,2] and [11,12].

But [1,5] w/ @L1, 1 only applies to [1,2,3] and 5 only applies to [11,12, 13].

I would think [1,5] w/ flatten will do the same thing as [1,5] w/ @L1.

I believe it’s the lacing assumptions being made by the parameters node (in auto) combined with the levels the lists are working at (by default the highest level in this case unless told specifically which level manually I think?). See in my example that longest/shortest is implied depending on lengths of lists being made to a node. In the first instance, shortest is being applied, and in the second, longest.

Try setting the lacing method in the parameters node and see if it changes the results in the first instance.

Usually with the set parameters node I will count the number of entries and generate a ‘list of repeated item’ for the parameter names in order to match the element/parameter list lengths, and ensure equal number of values are applied across these.

Flatten changes the list structure and therefore how most nodes handle the inputs and lacing. List levels do not change the list structure but specify how exactly a node should handle multiple inputs (in the form of sublists).

Look at how list levels works with the Flatten node itself.

Flatten expects a list input. List levels essentially changes where the “loop” occurs. With no list levels specified, the flatten function uses the entire input list (@L4) and flattens it. At list level 3, Flatten treats each sublist (@L3) as a separate input. The same thing happens for the rest of the list levels, affectively changing which sublists Dynamo treats as the “input” list.