Hi Patrick,
it's indeed implemented as a dictionary (so I can quickly binary
search the collection), but all the default tools should only give you
data structures that are proper trees.
Once you start to manually alter branch paths etc., it becomes
possible to have topologically incorrect branches, like so:
{0;0} with 10 items
{0;0;0} with 5 items
{0;4;9} with 2 items
this is a weird tree because the branch {0;0} has both items AND
subbranches, and because there is a large gap of missing indices
between {0;0;0} and {0;4;9}
The [Tree Branch] component only extracts exact matches. I can change
this behaviour. I do agree that what you expect to get makes more
sense than the current behaviour.
--
David Rutten
da...@mcneel.com
Robert McNeel & Associates
On Apr 1, 3:51 am, Patrick <patrick.ht.jans...@gmail.com> wrote:
> Hi all,
>
> It seems that is some instances trees are behaving more like
> dictionaries, where the dictionary key is the path, and the dictionary
> value is a normal list. The way that these trees are implemented
> 'under the hood' should of course make no real difference, as long as
> they behave like trees. But every now and then I expect something to
> work, and then I get thrown.
>
> For example, lets say you have a tree with a few paths: {0;0;0},
> {0;1;0}, {0;1;1}. If you pass this into a "Tree Branch" component, and
> you specify the path {0;1}, then I would expect to get out a branch
> with two paths in it: {1;0}, and {1,1}. But this does not work - it
> gives an error...
>
> Or am I thinking about this in the wrong way?
>
> Patrick
