Simplify Tree

Hello all,

Do it a little while I want to ask the question.

It's a bit subtle, but I have some problems for specific components.

Here, look good image. Why item on the tree simplification does not apply?

In the case of the tree component works perfectly. But for an item, nothing changes.

Why ?

Thanks for all

Replies to This Discussion

Permalink Reply by Danny Boyes on July 9, 2013 at 3:33pm

Hi Remy,

Pretend the Cluster is the Simplify Component. Does it work as you would expect?

Attachments:

SimplifyOptionsCluster.gh, 21 KB

Permalink Reply by Rémy Maurcot on July 10, 2013 at 2:24am

Thanks for all.

Danny, Luis & David....

I understand the context. And I just found a use for the example of Danny.

My reasoning is a little different, but it does not produce an error:

Attachments:

SimplifyOptionsCluster.gh, 36 KB

Permalink Reply by Danny Boyes on July 10, 2013 at 3:13am

Im not at my pc. What does it do for a single branch?

Permalink Reply by Rémy Maurcot on July 10, 2013 at 3:17am

Your example works for a single branch, but an error in the case of several branches.

With single branch:

Permalink Reply by Danny Boyes on July 10, 2013 at 6:51am

Okay so to summarise:

you are looking for the Removal of Zeros for a single branch when using the Simplify function.

Any whole number is relevant just the 0's are redundant unless they are all 0 in which case a single 0 is sufficient.

Is that correct?

Permalink Reply by Rémy Maurcot on July 10, 2013 at 6:54am

For me, yes !!!

Permalink Reply by Danny Boyes on July 10, 2013 at 7:17am

Me too.

@David, I know its your call in the end but "Simplify" should make things simple and where there is no context to refer to then the simplest form (without flattening) would be a great feature of this function. I know a lot of people struggle with this small issue.

It's user enabled so there is a Caveat Emptor presiding over the results much in the same way there is now by losing the whole tree structure.

Permalink Reply by Rémy Maurcot on July 10, 2013 at 9:47am

You give me so reason, Danny?

Many of us here think the same thing. the item should function as trees.

Permalink Reply by Danny Boyes on July 10, 2013 at 10:02am

This is lost in translation:

You give me so reason, Danny?

I do not understand the question.

the item should function as trees.

Although it will not work the same as trees. The simplify with multi-branches is removing similar branches. This will only be removing 0's.

e.g.

{1;1;1;3;0}

{1;1;1;4;0}

{1;1;1;5;0}

would end up after Simplify as:

{3}

{4}

{5}

But the single branch (remove zeros algorithm, as summarised above) would give:

{1;1;1;3}

Permalink Reply by AnewGHy on July 10, 2013 at 10:37am

If its a single branch surely the 'consistent' behaviour would be to default to simply {0}. I totally agree with Remy on that one.

Where's the logic in keeping it with multiple indices? If its for the purposes of 'data matching' (which has been used to defend the reasoning behind the 'logic' with previous posts I have made in regards to the subject), then would this not further strengthen the argument for a logical, more consistent and dynamic data matching system? I.e. if its one branch it gets condensed right down to just {0} - like flattening a 2D/3D... list, if further down stream other dependencies trigger the creation of more than one branch, of course that is where the existing logic continues to operate as currently programmed with the addition of a dynamic data address system that adapts to the flow/creation of data on-demand.

To me (and I'm sure to many other new users, and possibly even some more established ones) this type of behaviour would be more predictable, logical, consistent, intuitive and comprehensible.

Permalink Reply by Danny Boyes on July 10, 2013 at 10:44am

If its a single branch surely the 'consistent' behaviour would be to default to simply {0}

This feature already exists. Flatten will simplify a Branch right down to {0}

What I would be more interested in is the 1 and the 3 from the example above. As these might signify what geometry and which dependency it is associated with.

Permalink Reply by AnewGHy on July 10, 2013 at 11:04am

I'm aware that flatten does precisely that, but that isn't relevant to the point. I'm talking exclusively about the behaviour of data matching (Simplify, etc) which has more functionality and therefore an in-built logic.

What I would be more interested in is the 1 and the 3 from the example above. As these might signify what geometry and which dependency it is associated with.

If I want to simplify a tree to a single index that has one branch I'm not interested in what dependencies are associated with it; I can find that out by looking down stream, so there is no need to retain this information.

Maybe its terminology, 'Simplify' suggests the simplest version of something. {0, 1, 3} as an example, could quite easily be represented as {0} and would fulfil the expectations of this component. I would argue the vast majority of new users would expect the same behaviour.

Yet again it seems contradictory to say:

{1;1;1;3;0}

{1;1;1;4;0}

{1;1;1;5;0}

would end up after Simplify as:

{3}

{4}

{5}

But the single branch (remove zeros algorithm, as summarised above) would give:

{1;1;1;3}

In the multiple branch example, is this not losing the 'associated dependencies' you've mentioned? Then why have a completely different behaviour for a single branch? No wonder it so confusing to so many users. If we can crudely describe the above logic acting on multiple branches as condensing data addresses, why does this not apply with a single one? Really this is where the inconsistency rears its ugly head.