Thank you. Your method is much cleaner than mine.
I’ll look at your code. Thank you
I’ve seen so many attempts to explain Trees, and all of them makes me wonder if I missed something (I always perceived them as camouflaged “Lists of Lists”). So I wonder
#1. What are Tree’s if not equivalents to “Lists of Lists” (meaning, dynamic length of the “paths”, or indexes)
#2. If Tree’s cannot directly be copied into the following Lists of Lists, what are they then?
Fig. Array’s of Arrays, or Lists of Lists (which can be essentially the same thing under the hood) of char. Indexes are grey
// Rolf
6 Likes
Sure, but you will find simplify doesn’t always work as you might need. Suirify is the safer bet in this case. Just ask @osuire 
1 Like
What’s the difference?
I never use Surify, I’ve always wondered why it’s necessary. I don’t mix trees of different path lengths, and if I do, I simplify the inputs. Really, I’ve never used it.
There are some cases when the zeros don’t get simplified down further, Suirify just ensures that no matter what, the paths are single number addresses in all cases. Honestly, I don’t use either much as I don’t find myself splitting out branches manually in many cases.
Suirify is beginner’s best friend. I always use it when there are operations involved two tree structures. It helps to understand better on what is happening.
I see existence of Trees in GH simply showing the disadvantages of statically typed languages.
if GH would support translating Python Lists (nested lists) into GH lists (GH Trees) it all would be much easier to use and understand.
1 Like
== BEST GUESS ==
Huh? The Structure for storing data is not the same thing as the Types of the Data it contains.
If you want “any type” data scrambled in your bags of data, then you can wrap your values inside objects, or address them with pointers, or whatever (picking your language accordingly). Then put the lights out and guess what went wrong, when it most often do.
The reason why typed languages came into fashion was to avoid the endless and hard to track bugs (means, lots of unproductive work hours hunting bugs) which is so typical for untyped languages.
But as with any tool, the requirements, the usefulness and efficacy of static types (in terms of reliability, maintainability, the scale and complexity etc) depends on what kind of software you are trying to build. Hence the “huh”.
// Rolf
All languages are typed afaik. Anyways, statically typed languages came to exist before dynamic ones, and we can’t speculate why they exist. But the dynamically typed ones came to be to remove the abundance of crap boilerplate code you have to do for each single task.
As I said, what I meant, is the same thing Tree does you can do with Python objects without the unnecessary type requirements.
Storing a list of different types in GH, is hard, if not impossible. A nested one rather impossible. And quite easy in Python with proper usage of list() tuple() and zip().
Another guy having problems with Units (the guy doing the programming calculating the trajectories for Apollo):
Sigh.
In this panel he was joking something like “I know what happens if somethings goes wrong [with his programming]. We either get half way or double as far” (only some people understand what he was saying).
No, not all languages are typed. You don’t know what you are talking about.
// Rolf
please do tell. Teach me a lesson. You’d like that.
Same, mainly for the fact that I never really needed it, but also because I don’t like that it is blue and stands out from all the rest of components.
Collections have nothing to do with that, it has to do with putting things together, it doesn’t matter what things are. If a collection instead of being generic becomes typed, it’s because that restriction matters, because different types can have different behaviour. The existence of data trees has to do with synchronizing inputs that may have different access dimensionality.
In .Net languages you have many alternatives to make data structures that work like data trees, or everything you want to do in python, just as easy. You confuse implementation with language limitations.
No for the developer, yes for compiler. The language is in between, if you don’t need to set the type of a variable, then is not a typed language, as javascript.
What? Why? you have parameters for generic objects that works as a non typed collection.
Nested collections in GH are a problem because GH works by cloning the data to break references with the previous component data state. If you try to clone a child element, do you also clone the parent or keep the reference? and if you have to clone the parent, what has become of the child? You loose the references or links if you clone one by one, you just can clone all as a whole and that loose the nested collection capabilities. It has nothing to do with the language.
You can do exactly the same thing with .Net. You’re mixing up unconnected things.
2 Likes
The main thing you should understand of what I say is placed in my first reply:
No, I don’t understand how a collection conversion method can help to better understand the data trees, which you understand them when you learn how GH synchronizes the inputs to solve the components and that they’re list of labeled lists.
that’s because you’re experienced programmer. Most of us aren’t.
Don’t drive the car before learning how to drive it.
// Rolf