Why is it so hard to append an item to a tree? Am I going mad?

unhandled

(Alex) #1

Hi all,

Am I going mad here? I have a tree {X,Y}(Z). I want to insert an item after {-1,-1}(-1). I’ve tried so many ways but cannot do this? Insert item only works for lists, and GHPython does not handle trees at all logically (I cannot get it to read a tree to do a simple list.append(x) task!

I’m rather stressed about this! Is there an easy way I’m missing?


(David Rutten) #2

If you’re using negative indices you’ll always run into trouble. Either immediately because of a index-out-of-range exception or down the line because most logic expects non-negative indices.

You posted this in Grasshopper, not Grasshopper Developer. Is this a Python, a C# or a vanilla GH question?


(Alex) #3

Hi,

Honestly, I just need it to work; ideally in native GH. Hopefully the image clarifies. I’m sure it is a simple task - however I am getting mighty frustrated that I cannot do it easily in either GH vanilla or Python! I’m sure this is user error.


(David Rutten) #4

One way is to flatten and merge:

And here’s a path mapper approach:


(Alex) #5

David,

I feel like a muppet. Thank you so much for the fast response though. The former works absolutely perfectly!


(David Rutten) #6

It would have been nice if there was an insert component that worked on trees though. There’s a lot of consistency still lacking in the feature set.


(Lli) #7

I am interested in writing a component to do that. What language is best to use? I am most comfortable with javascript and python…

We can add some tree related operations such as insert, delete… and maybe BST, not sure how it would be useful for designers though…


(Tom) #8

the funny thing is, the moment you start to script in grasshopper, you actually don’t need much tree manipulation anymore (and you don’t want to solve these little Sudokus all the time). “DataTree” is a C# construct, you can call it from Python but it doesn’t feel pythonic. Although I believe Tree management will always be difficult within a visual programming language. So I don’t think DataTrees are bad implemented.


(Lli) #9

Yeah that is true… Maybe it would be useful for some gigantic urban planning projects with millions of data… but at that point you will have to use database in some other platforms than Rhino…so…

But thanks for the note Tom.


(David Rutten) #10

Sadly the scripting components are not great at providing tree features. In grasshopper proper data trees are stored inside a class called GH_Structure<T> with a type constraint on T for IGH_Goo. It was felt that that was needlessly complicated in scripting components, so a second tree class was created called DataTree<T> with no type constraints. What you really want is for tree operations to not mess with the data inside the tree at all, only with the tree layout itself. This is not possible in scripting components, since they will convert a lot of data types into simpler types, ditching a bunch of information along the way.

You can’t make it work for booleans and integers because null-states are lost when converting to a struct. You can’t make it work for Points, Curves and Breps because reference information will be lost.


(Lli) #11

Interesting, it is much more complex than I thought… Thanks for the information David.


(David Rutten) #12

Also more complex that it should have been. In GH2 this works completely differently, doubtless there will be new problems, but none of this double-bookkeeping/data-layering horse exhaust…