Allow more easily responsive algorithms.

Hi,

I would put to debate and consideration of David, the next idea.

Problem:

When an algorithm is performed, one has to be aware of the data structure (item, list, tree) that will be used on parameters. By default algorithms are created not responsive, that is, can that work fine with data in lists, but if you add branches in a parameter, the algorithm does not work. This can be corrected of course, adding the necessary procedures. In fact it was what I had to do with Peacock v0.96 (are user objects) with more or less good result, but almost all bugs come from this. External plugins help to deal with branches, but should be able to do easily with native components (the Shift Paths component fails when you run out of branches is a big mistake). But it is also fair to say I've always been able to solve it with native components (or with some code maybe).

I still find me with this problem very often. Make a responsive algorithm can greatly complicate things, and it's something that from code does not happen. Script components or compiled components, and definitions (as an individual) or UserObjects, do not work in the same way to process the data.

Code components work perfectly when using different data structures of the access type of its parameters. How could do this for entire definitions?

Possible solution:

In the container components (parameters), those of hexagonal icon with black background, can assign access type, so that data are transmitted depending on the type of access, as the components work.
Thus the parameters of the User Objects or definitions can be set to operate with a specific type of structure, and when it receives other structure, the definition will be executed directly in appropriate manner.

This have sense? forced to move too many things? there would be a better solution?

Thank you.

Replies to This Discussion

Permalink Reply by Andrew Heumann on April 5, 2016 at 5:39am

this is the approach dynamo takes and it causes endless headaches and frustration. the problem is not the structure in-and-of-itself - it's how structures match with each other. if I grab the "first item" of a list of lists... should that be the first item of every list (GH approach) or the first list (dynamo/python approach)? I for one think that data trees, while certainly not without challenges/frustrations, are MUCH more flexible for real world design tasks than the rigidity of arrays of arrays of arrays of...

Permalink Reply by Nik Willmore on April 5, 2016 at 6:04am

Your IQ is about 145.

Mine is 130.

Most designers, 110.

It will take me many months to grok your statement, but at least I am not longer so confused, in principle.

Permalink Reply by David Rutten on April 5, 2016 at 7:17am

It's just not flexible enough to have a single level of hierarchy.

Unless you can show me how I can deal with the problem described in this post using a list of lists it's not an alternative.

Of course a datatree is a list of lists when you get down to it, it's just that each list has an additional identifier which allows it to occupy a more complex position within a hierarchy. If you don't want that, renumbering the paths in a tree to {0}, {1}, {2}, {3}, ... will make trees behave the way you want. Renumbering will be part of every parameter post-process options in GH2 (along with some other common modifiers such as 'remove last element from all paths').

Permalink Reply by Andrew Heumann on April 5, 2016 at 12:08pm

For the record, my view is not just from the perspective of a power user but also as a teacher who has taught many seminars on grasshopper and Dynamo alike. Both programs pose their own sets of challenges with respect to data management, but most new users find data trees more powerful and intuitive than the Dynamo approach. ¯\_(ツ)_/¯

Permalink Reply by David Rutten on April 5, 2016 at 12:44pm

One possible alternative to tree management in GH2 will be metadata. It'll require a more hands-on approach, but basically you could just throw everything into a single unordered collection and select whatever data you want from it using keys... I have no idea yet how performant/feasible that approach would be, but it is an alternative of sorts.

Permalink Reply by taz on April 6, 2016 at 8:16am

Each branch would have a tag, annotation or descriptor?

Something similar to how a mesh vertex stores color info (i.e. another layer of information in addition to the primary data represented)?

Permalink Reply by David Rutten on April 6, 2016 at 8:35am

Each item can have any number of non-conflicting key-value pairs. Branches are not now (and probably won't be) associated with any meta-data.

Permalink Reply by taz on April 6, 2016 at 9:45am

Ah, I get it. Interesting in theory, possibly very confusing in execution.

When data trees first appeared they were the least graphical (most abstract) GH feature - harder for people w/o any passing knowledge of programming to wrap their head's around.

We must remember history... yada, yada, yada

Edit: Just read your "Why and How..." for the first time again. A new dictionary type "storage mechanism" is what you're implying?