tree datastructures matching

Replies to This Discussion

Permalink Reply by gennaro senatore on July 29, 2010 at 5:34am

added imange to previous post to clarify the issue

thanks

• ▶ Reply

Permalink Reply by taz on July 29, 2010 at 7:19pm

Gennaro,

I believe to be on the safe side it's best (best meaning most predictable/stable) to try and make your tree structures identical.

There are exceptions... I think for most transformations you can get away with leading zeros (see below):

But if you try to merge mismatching trees then leading zeros do matter.

Sometimes you can also get away with matching trees and lists but the resultant behaviour is much harder to predict.

• ▶ Reply

Permalink Reply by gennaro senatore on July 30, 2010 at 5:07am

hello Taz,

thanks for replying,
I understand what you say about best == predictable and I think it is a good reason
in principle I do not have any problem with matching trees by making them identical
my only concern is on the increase of information==memory that this sometimes brings about

for instance in the previous case I had 6 surfaces and 50x6 polylines to remap from 2D to the surfaces (50 polylines for each surface)
the control points on each polyline needs to be kept in third order hierarchy to be able to rebuild the polylines after the points are remapped on the surfaces. For this to happen to I had to duplicate those surfaces 50x6 times, basically 50 times the same surface for each list of 50 group of control points; which I reckon increases substantially the amount of necessary information.
if you do a nested for loop you keep only 6 surfaces and you use each of them for each group of 50 polylines

which is why I thought that by matching only the higher order hierarchy we could kind of make this to happen......

any thoughts ?

• ▶ Reply

Permalink Reply by taz on July 30, 2010 at 1:19pm

I understand what you're saying, but I don't have any answers. Tree management is David's department and I think he might be tied up at SIGGRAPH this week.

Sometimes you can get things to work without duplicating the data and sometimes you can't, but it will always depend on what specifically you're trying to do.

This is another example of how components can behave differently when using trees... For [Pull Point] it needs duplicated data with matching path names. For [Closest Point] it doesn't.

http://fancywires.com/?p=486

The whole concept of trees is fairly experimental, new as of the 0.6 version of GH. Tree structure isn't intended be exactly the same as arrays, which leaves the rules of their operation to be defined by David (but he takes suggestions...).

In summary: Trees != Arrays

• ▶ Reply

Permalink Reply by taz on July 31, 2010 at 5:46pm

Also see this discussion (trees from a scripting perspective):

http://www.grasshopper3d.com/forum/topics/input-read-trees-in-scrip...

• ▶ Reply

Permalink Reply by gennaro senatore on August 1, 2010 at 8:07am

thanks for the links Taz,

I certainly agree with you when saying that tree!=arrays but the example made of looping through 2nd order hierarhcy for each 3rd order hierachy (the surfaces with the points of the polylines.....) can still be done with trees and a nested for loop without replicating unecessary information (which is caused when you make those two trees with identical structure)
this can be done simply with 4/5 lines of code but since GH is so cool to use without explicitely coding I still think that this could be implemented if not already present acutally with me being not aware of the right procedure

please find attached this small definition, just to make sure that I have managed to explain myself properly. please start reading after the breaking line as indicated

thanks

Attachments:

• tree datastructure matching.ghx, 313 KB

• ▶ Reply

Permalink Reply by Jacek Jaskólski on August 1, 2010 at 9:36am

Hi guys,

It looks like the order of input is relevant:

So in case of components which perform commutative actions (like the one above) the solution is to choose the right order of inputs.
The result stream inherits the data structure of the first input tree.

In case of non-commutative components we still seem to have a problem...

• ▶ Reply

Permalink Reply by gennaro senatore on August 1, 2010 at 10:07am

thanks Jacek,

absolutely right.... this happens because we just do not know the way in which command are implemented although we could read a bit GH library and try to get a better understanding
it is just a matter of managing data, which is why I think that we should not duplicate unecessary information to get the matching....
as Jacek points out in case of "non-commutative components" we still have the problem (please see file attached, as usual start reading after the line breaking line please)
if this hasn't been already implemented and it is not possible to achieve it in simple ways I reckon could be a good suggestion to be implemented

Attachments:

• sample.3dm, 1.2 MB
• tree datastructure matching 2.ghx, 446 KB

• ▶ Reply