Data Trees and Nulls / Wish

I originally tacked this on to the end of another thread but I think it got lost there at the bottom.

It seems to me that the default behavior around trees and nulls is in general fairly counter-intuitive, especially with intersection components. I can't think of any situation where having the nulls in {A;B} and the successful intersections in {A;B;C} would be useful. I always end up having to resort to any number of weird tricks to get them to line back up. If I want the same definition to work with different inputs, where in some cases only valid intersections are produced, and in other cases certain intersections fail, I'd like to be able to count on the data trees being consistent, whether they contain nulls or not. It would make a lot more sense to me to have the results from an intersection always go to the same branch, whether or not the result is valid.

Here's a more concrete example. Say I have a definition with some curve intersections and I want to label the intersections of the curves. When all intersections occur, the labeling works fine, since the paths all match up. However when some intersections fail, everything goes haywire, and the data tree of the intersection results needs some major coercing + manipulation in order to get it to match the structure of the labels.

Is there a reason why nulls get grouped in shorter branches, while successful results get separated into individual branches? My feeling is that the default behavior ought to be changed, but perhaps I'm missing a case where it would be beneficial. Also, I'd be very interested to hear clean workarounds for this type of case if anyone has them; I have a few of my own but they are pretty hack-ish and don't always work consistently.

Replies to This Discussion

Permalink Reply by Danny Boyes on May 23, 2012 at 2:47am

But the data (not path) structure is different so it would be Path Structure Matching.

If it was only based on Path structure and my example before of 10 curves on 2 Branches

{0;0}(N=5) {0;1}(N=5)

was matched with

{0;0}(N=5) {1;0}(N=5)

you would wish for {0;0} --> {0;0} and {0;1} --> {0;0}

because it would recognise {0;1} is a subbranch of {0}

is that right?

Permalink Reply by phillip on May 23, 2012 at 3:15am

Not really. In this example

{0;0}(N=5) {0;1}(N=5)

was matched with

{0;0}(N=5) {1;0}(N=5)

the desired output would be

{0;0;0}(N=x), {0;1;0} (Null), {1;0;0} (Null)

since they already have the same pathlength, you wouldn´t match

{0;0} with {0;1}

---> only if there was a path called {0} as well, but asuming it is not possible to have different pathlengths in one tree, this wouldn´t be a problem

I am not sure how to handle inputs with different pathslength coming from different sources though, I guess this would cause an runtime-error.

Permalink Reply by David Rutten on May 23, 2012 at 4:05am

but asuming it is not possible to have different pathlengths in one tree, this wouldn´t be a problem

This is possible. There is nothing illegal about a tree with paths like this: {0}, {0;0}, {0;1}, {0;0;0}, {0;0;1}

David Rutten

david@mcneel.com

Poprad, Slovakia

Permalink Reply by David Rutten on May 23, 2012 at 4:00am

Note that it is quite easy to modify the number of branches in a datatree through some variable —say a slider— but far more difficult to modify the paths themselves, unless you specifically employ path modification components of course.

The thing I want to avoid at almost all cost is that dragging a slider will sometimes result in one matching logic and at other times in a different matching logic. Can you imagine trying to write PathMappers for a file that sometimes works one way and sometimes another?

There should be a single behaviour that is consistently applied across all components, regardless of whether their datatrees line up or not.

David Rutten

david@mcneel.com

Poprad, Slovakia

Permalink Reply by Danny Boyes on May 23, 2012 at 4:16am

Consistency is key to the whole process , I agree.

Permalink Reply by phillip on May 23, 2012 at 4:38am

I see. If there is no whish of avoiding various structured trees, I totally agree. Thanks!

Permalink Reply by phillip on May 23, 2012 at 2:05am

Hi David,

regarding

what do you think should be the default behaviour in this case then:

DataTree a: {0;0}, {1;0}, {1;1}

DataTree b: {1;0}, {1;1}, {1;2}

I think the output should always keep all the input branches, no matter what happens. Because as you say, its easy to remove empty branches.

I´d appreciate it, if there was simply no possibility to create a DataTree with different branchlenghts at all.

DataTree a: {0;0}, {1;0}, {1;1}

DataTree b: {1;0}, {1;1}, {1;2}

would always create

DataTree c: {0;0;0}, {1;0;0}, {1;1;0}, {1;2;0}

even if {0;0;0} and {1;2;0} are <null>

Thanks,

Phillip

p.s.: I think relItem should also always stick with the input Treestructure of all branches, because its easier to match b afterwards in case needed.

Permalink Reply by David Rutten on May 23, 2012 at 1:24am

The empty list bug seems to have already been fixed, however the empty list still disappears when Grafting because Grafting only looks at actual items stored in the tree. I think Grafting should take into account empty lists and just append a ";0" to each one. It is after all easy to remove empty lists from a datatree, but damn near impossible to reinstate missing ones.

David Rutten

david@mcneel.com

Poprad, Slovakia

Permalink Reply by Richard Schaffranek on May 23, 2012 at 1:31am

thx...

Permalink Reply by Stan Carroll on May 23, 2012 at 4:20am

I am so encouraged to see so much productive energy is being placed on tree structure. I place this area of refinement to be paramount. Keep up the good work.

stan

Permalink Reply by Richard Schaffranek on May 24, 2012 at 8:26am