What is the most efficient way to produce a ‘tree of trees’?
Do I have to use the path mapper?
I can’t seem to figure out how to utilize the graft and flatten components to this effect; is it possible that there is a fundamental error in the Grasshopper Data management system? Must I use path mapper, or is there a shift paths or other component trick that I may use repeatedly to create further subsets within subsets (within subsets, etc.)?
It gives me the feeling that the Graft component is a ‘one-time-use only’ device, after which it is permanently broken.
To clarify, in the attached image: in Figure #2, I was attempting to create the effect in Figure #3 [?] .
If you click the image (after you click the image) it magnifies the image, and you can clearly see not only the file (which consists only of a few components (6 and 8 respectively, to be exact, plus 4 number sliders)), but also exactly what I want to achieve.
So, to clarify:
Explain what you want to achieve
Check! Clearly indicated in Figure #3, Figure #4, and Figure #5 .
Explain what starting data you have
Check! Clearly indicated in Figure #1 and Figure #2 .
It is a sorted list (by a multidimensional indexer) of lists (technically it is a SortedList< GH_Path, List< object> >). It’s more like a list of lists than a tree, which is a structure where each element has a link to a parent element and several child elements. You can’t nest data with it, you can interpret that it does however, but it behaves like a list of lists with the difference that the sublists are labeled with several indexes that follow nested rules.
I guess where I wanted to go with this is, that the trees don’t naturally behave as multidimensional arrays. I guess you can store multidimensional arrays in trees if you organize the data in a smart way (up to the dimension of 3? 4?), but the multidimensionality won’t come naturally from grafting.
Well, if by tree you mean datatree, the problem is that they’re not really trees. If I remember correctly, in GH2 they will have another name, and in fact, its origin is GH_Structure< IGH_Goo> and the class DataTree< object> was an attempt to make it easier to operate with them and generally for any type, without restricting it to IGH_Goo which is a wrap of all data in GH1, but if Rutten reads this, please correct me if I am wrong. That said, datatrees can be interpreted as multidimensional arrays, but so can trees. An array does not necessarily have the same number of elements in each dimension. Regardless of interpretations/how they are used, the technical difference is how you jump from one element to another in memory to read or write. In lists/1d arrays, you have to go one by one (and if they are value type data they will be stored one by one in memory), in trees, each node knows the accesses to its parent and descendants (and they can be “randomly” located in memory), and in datatrees, it is like a 2d list, first you go through the paths one by one to the desired one and then one by one each element in the list/branch to the desired memory position/index/element. Maybe it’s not well explained, but this is where the difference really lies, its fundamental dimensions, which can be viewed different depending on the interpretation/use/layers of complexity to operate with.
Grafting, yes and no more dimensions are added. Not because it is still a list of lists and yes because you can interpret your new data organization as another degree of freedom within a given context. For example, a 2d grid of points in a flat list has 1 dimension (you need a list index), if you group them in a datatree between rows and columns you have 2 dimensions (branch index and list index), if each column you divide it in several subgroups, you have 3 dimensions, because to access some element you have to first know the column (first index of the branch), then know the subgroup (second index of the branch) and the position in that subgroup (list index).
Agreed. I’ve coded many algorithms with multidimensional arrays (when knowing the number of items beforehand) for processing in parallel loops etc (avoiding data races), and then at the end of the algorithm I re-packaged the processed array data into DataTrees. Very straightforward.
Seems it was not mentioned yet. A tree is a collection of lists, where each list has an identifier, the GH_Path. To make it unique, this path is basically an array of ints which reflect the deepness within the tree and so clearly identifies each list. There is no tree of tree, its just the path which gets an additional number for a higher dimension.
However trees are not necessarily the best data structure. You could encapsulate things in objects owning objects owning objects etc. This is much more readable on coding level.
e.g. A grid object owns cell objects which own cellelements/geometries
