WISH : no trailing zero option

I still haven't figured out why some components insist on adding a trailing zero in the output tree structure while others just mind their own business.

At first, it led me to using the "Simplify" option like crazy, which had the adverse effect of screwing up my definitions when upstream data had varying levels of branching.

(Thanks to Andrew Hewman for pointing out that "Simplify" was an "absolute" operator, and that I should stick to "relative" operators to have robust definitions).

I use the path mapper to get rid of the extra branching, but I'm sure that this might also spell "trouble" if the upstream tree structure changes.

So I think it would be nice to have some kind of toggle inside the component to block this nasty branching mania.

Replies to This Discussion

Permalink Reply by Olivier Suire on September 7, 2017 at 5:56am

Really ?

No one's interested in this ?

Permalink Reply by David Rutten on September 7, 2017 at 9:56am

I'm not supposed to work on GH1 any more, so this is going on the GH2 pile. GH 2 will be different in many ways, so maybe your suggestion is exactly what will happen, maybe something similar will happen, maybe the problem isn't relevant any more.

Permalink Reply by Olivier Suire on September 7, 2017 at 10:06am

Ah... No more evolution for GH1 then....

I wasn't aware of that.

Permalink Reply by David Rutten on September 7, 2017 at 2:41pm

GH1 has been on feature lockdown for over a year. We do still fix bugs, and sometimes new features are added to stop us all going insane, but we're not supposed to make any major changes this close to Rhino6 release.

The new multi-threading is a bit of a break on this, but I suspect we mostly wanted to test our own SDK for thread-safety, and this seemed like a good way to do so while having a beneficial side-effect.

Permalink Reply by Olivier Suire on September 7, 2017 at 2:54pm

Ha ha ! You play with the multithreading fire but you won't add a little option to the components ?

This would not break the SDK or even any existing definition.

It would just make life in the woods much easier for the coming years.

Didn't you say that GH 2 won't come before Rhino 7 ?

I sure would like to see easier tree management before I get my first hip joint replacement :)

C'mon David, pleeease !

Permalink Reply by David Rutten on September 8, 2017 at 2:25am

Ha ha ! You play with the multithreading fire but you won't add a little option to the components ?

This would not break the SDK or even any existing definition.

Well, I was as surprised as you to find Steve had started on multi-threading. I'm sure he had good reasons. We do need to get our SDK as threadsafe as possible as quickly as possible, because sometimes during the Rhino6 life-span the amount of processors in computers will become a far more important metric than the speed of any one of those processors.

It might not break the SDK (almost any change is a potential break), but worse, files that use (and need) this feature will no longer work when loaded on earlier versions. Although there are already plenty of new 'standard' components in Rhino WIP, so file exchange is already compromised.

To be clear, the 'Don't Add Branches' thingy you're suggesting is like Simplify, but only for zeroes on the right-hand-side of paths?

Permalink Reply by Olivier Suire on September 8, 2017 at 6:23am

sometimes during the Rhino6 life-span the amount of processors in computers will become a far more important metric than the speed of any one of those processors.

Well, based on past intervals between major releases, we will probably see quantum processors in cheap Asus laptops before Rhino 7 WIP is on the horizon !

Here is an illustration I did to make sense of this branching imbroglio:

So YES : I wish there was a "No extra right hand side zero" option.

Permalink Reply by David Rutten on September 9, 2017 at 1:56am

So YES : I wish there was a "No extra right hand side zero" option.

That's not the same thing though. Are you asking for a option which removes any and all rightmost zeroes shared amongst all paths in a tree. An option to remove only a single rightmost zero if it's shared amongst all paths in a tree. Or an option which doesn't add any additional zeroes to the outputs, but leaves them intact if they were already there?

Permalink Reply by Olivier Suire on September 13, 2017 at 8:56am

Hi David,

All three possibilities could be useful I guess.

By "No extra right hand side zero" I mean "Please Mr. component, don't add right-hand branching if it results in all-zeros".

Does that make sense ?

Cheers,

Permalink Reply by Andrew Heumann on September 21, 2017 at 2:31pm

An option which has been discussed before and is not too different from this is a "shift paths/trim tree by one" modifier in the right-click menu. I think this covers 95% of cases - if you KNOW that for your definition you will NEVER wind up with multiple results for a single input for a given operation, then pshift-by-1 and be done with it. It would be lovely to have this as a right-click menu option.

However, in my opinion, safe and predictable use of data trees means only *relative* operations (that means: no flatten, no path mapper, no simplify) - this is how you ensure that the tools you build can survive upstream structure change. I am not a fan of anything more complex than this - including olivier's *conditional* modification of the path structure (p-shift if all 0s but not otherwise) - upstream changes with such a system will break the shit out of your definition.

Permalink Reply by Olivier Suire on September 22, 2017 at 1:54am

Hi Andy, I understand your point, but my tiny brain can't keep track of what each branch represent in trees which keep growing with no actual "meaning" in the context of my definition.

Therefor, I need to groom constantly to keep the tree structures intelligible.

Recently, I have been using "Trim tree" to that goal : I know that it would break the definition if the input structure is different, but I know for sure it can't happen.

The above definition answers a very specific and concrete need for our engineering purpose, and the process is well framed ; therefor I am confident that the trimming will never have adverse effects.

I like your description of the more robust simplification process I was suggesting : "p-shift if all 0s but not otherwise", it is quite concise.

Maybe it can be done with regular components and made into a cluster that would be appended to the outputs who insist on growing my trees :)