How to manage these data trees ?

As new data tree logic was introduced, I still have problems understanding it. I know (Ive read about it) that there is master and slave tree, but it remains unclear for me. Why outputting tree has 540 paths (like bottom one), but with order like in the top one (so path is formulated as one integer)....

I want to find closest point in each of 3 from bottom tree. {0} from top one with each {0;x} from bottom etc.

Replies to This Discussion

Permalink Reply by Andrew Heumann on August 24, 2012 at 12:49am

I can't give a good explanation of the new default data matching behavior between mismatched trees - but in my experience there's almost no matching situation that can't be achieved with a little list manipulation. I used to do this with a lot of item duplication, and now the cross reference component makes it a fair bit easier.

In my experience, for predictable path behavior you always want your data tree structures to match. Trying to run a component with two non-matching structures basically never gives you usefully structured results.

In the above example, I would put both the grafted list of points and the curves you're dividing into a cross reference component. Then graft the A output of the cross reference so that the points you're searching from also have 540 matching branches.

In general, you can (usefully) match 1 item against 1 item, 1 item against N items, or N items against N items. The same applies for paths; you can match a flat list against a flat list, a flat list against a structure S, or a structure S against a matching structure S.

As to why GH handles the case of matching non-corresponding structures the way it does? only David can answer that...

Permalink Reply by Danny Boyes on August 24, 2012 at 3:32am

I can't seem to get the results needed with the Cross Reference Component, there still seems to be longest list matching to the cross referencing i.e. in the example below {4} of List A gets Matched with everything after {0;4} of List B.

Here's a duplication method like Andrew was talking about:

Permalink Reply by Mateusz Zwierzycki on August 24, 2012 at 7:11am

Well, it seems that's just a bug or I may revert to practice more with digitaltoolbox.info ;)

And here is an usual workaround which works now, and worked well in 0.8066 too.

Permalink Reply by Andrew Heumann on August 24, 2012 at 8:04am

oh interesting, that does seem like a bug. I should have tried it in GH before running my mouth :P

Permalink Reply by Andrew Heumann on August 24, 2012 at 9:43am

On further reflection, I don't think it's really accurate to call it a bug; it's the difference in tree matching between item-item and item-list.

Also, you'll note that in the first example you give above, even though the line component gives what APPEARS to be the expected structure, it's not really making a logical matching either.

I stand by my earlier statements; everything will go well so long as your tree structures and lists match 1:1, 1:N, or N:N. We can argue about the "right" implementation for an M:N situation but it's an ambiguous case... what works for one situation will surely be counter-intuitive for another.

If, as in the above example case, we have a structure where M = {A} and N = {A;B}, it's clear that we want the groupings to correspond from A : A. However if M = {A} and N = {F;G}... who knows what should happen. From the perspective of the component it seems to me there's effectively no difference between these two cases.

RSS