Dynamo: Using new list management features producing inconsistent results for both List.GetItemAtIndex node and DesignScript

[ThomasMahon]

Dynamo version

1.2

Operating system

Win 10

What did you do?

Two exercises using the new list management features, 1 with a node, 1 with DesignScript:

1. Use List.GetItemAtIndex with a 2D list utilising the new list management feature @L2. I also ticked the box to maintain list structure.
2. Used @@-2 in DesignScript and attempted to index the same list

What did you expect to see?

In both cases:

A 2D list, each sublist with a single item

What did you see instead?

1. Using the List.GetItemAtIndex node doesn't honour the list structure
2. In DesignScript there doesn't appear to be a way of using the @@-2 semantics with indexing, it simply returns the object from L1

[dimven]

I don't think you can apply a level like that in DS. Levels work only with the inputs of a function. For example: List.GetItemAtIndex(x@@-2,2)
Tho it does seem that GetItemAtIndex does not agree with the level syntax.

[ThomasMahon]

There's definitely room for improvement then. Hopefully Dynamo 2.0

[dimven]

@ke-yu the below syntax is correct?

[ke-yu]

@dimven it is correct. The difference between code block node and the UI node is, UI node will append a replication guide <1> if you use list@level.

@Racel and I had some discussion, and we think list@level is to replace List.Map work flow, so appending a replication guide (that is, List.GetItemAtIndex(xs@-2<1>, 2) enforces a for-loop. Similarly, if multiple inputs use list@level, they will do zip replication, that is to replace List.Combine.

[ThomasMahon]

@ke-yu what about the List.GetItemAtIndex(xs@-2<1>, 2) node not appearing to support the 'Keep list structure' option? Is that correct or a bug?

[ke-yu]

@ThomasMahon List.GetItemAtIndex(xs@-2<1>, 2) or List.GetItemAtIndex(xs@@-2<1>, 2)? @@ to keep list structure.

[ThomasMahon]

@ke-yu I meant this. For some reason the list structure isn't maintained, despite specifying that it should:

[ke-yu]

@ThomasMahon the list structure is kept for this case, right?

List@Level gets a list of sublist and set them to List.GetItemAtIndex. For for 2nd sublist, {3, G-X, 14, 1}, we get value 14, and write it to back the original "slot" of {3, G-X, 14, 1}

[ThomasMahon]

@ke-yu Yes. However, I am expecting a different result; to me 'Keep list structure' should be exactly that, meaning if a 2D list goes in, a 2D list comes out. However, it seems a rank is discarded when using this feature. The question is then, why 'Keep list structure' (by design), only operates on lists beyond rank 2?

I do have a number of cases over the years where I have had to use 3D or 4D lists (cant think of any cases where I've gone beyond this) but there were very specific reasons for doing so. The typical user is unlikely to venture into using this kind of data structure meaning the 'Keep list structure' in most cases is largely a redundant feature. Be good to get some clarification on this.

Also, the 'Keep list structure' description states _"Keep 1 input list's nesting"_ and that too is somewhat misleading:

[ke-yu]

@ThomasMahon
In this case List.GetItemAtIndex() takes a list and returns a _single_ value, that's why the rank is reduced. What result do you expect though?

For 1D list, pulling a value from its location, processing this value and writing result back to original location still generates a 1D list, so keeping list structure or not won't have any impact on the "structure" of result.

[ThomasMahon]

Ultimately it centres on what 'Keep list structure' is supposed to do. If I don't use it, and if we stick with the List.GetItemAtIndex() example, then I would expect rank reduction. However, since I see no difference in behaviour when using 'Keep list structure' until I get to rank 3, I'm questioning whether this feature is too ambiguous and/or requires more attention.

You describe the processing of 1D list returns another 1D list; following the same logic for a 2D list (where 'Use levels' and 'Keep list structure' is on) I would expect a 2D list to be returned. 3D list should return a 3D list and so on...

[ke-yu]

Oh I think it does, unless the node reduces rank...

[ThomasMahon]

@ke-yu if I understand correctly then, it works more like a hierarchy; if the node reduces rank, 'Keep list structure' applies once the reduction has occurred otherwise 'Keep list structure' behaves the way I initially expected it would (i.e. 1D in 1D out, 2D in 2D out etc)

[Amoursol]

Thank you for the submission of this Issue above - We very much do appreciate your time taken to look to improve Dynamo and help it grow and evolve into the future.

In order to better serve the active Dynamo user base and the evolving nature of Dynamo, the Dynamo team has made the decision to close any issue that hasn't had activity since 1st January 2019. This doesn't mean that these issues will not be addressed, but just that they are not being actively worked on as they do not align with our current Dynamo Public Roadmap.

If this issue is still relevant to you and your workflows, please do re-submit in a new Github Issue and link to this closed issue for historical context.

Many thanks,
The Dynamo Team