ng is deciding how and where to store your data. If you're writing textual code using any one of a huge number of programming languages there are a lot of different options, each with its own benefits and drawbacks. Sometimes you just need to store a single data point. At other times you may need a list of exactly one hundred data points. At other times still circumstances may demand a list of a variable number of data points.
In programming jargon, lists and arrays are typically used to store an ordered collection of data points, where each item is directly accessible. Bags and hash sets are examples of unordered data storage. These storage mechanisms do not have a concept of which data comes first and which next, but they are much better at searching the data set for specific values. Stacks and queues are ordered data structures where only the youngest or oldest data points are accessible respectively. These are popular structures for code designed to create and execute schedules. Linked lists are chains of consecutive data points, where each point knows only about its direct neighbours. As a result, it's a lot of work to find the one-millionth point in a linked list, but it's incredibly efficient to insert or remove points from the middle of the chain. Dictionaries store data in the form of key-value pairs, allowing one to index complicated data points using simple lookup codes.
The above is a just a small sampling of popular data storage mechanisms, there are many, many others. From multidimensional arrays to SQL databases. From readonly collections to concurrent k-dTrees. It takes a fair amount of knowledge and practice to be able to navigate this bewildering sea of options and pick the best suited storage mechanism for any particular problem. We did not wish to confront our users with this plethora of programmatic principles, and instead decided to offer only a single data storage mechanism.*
Data storage in Grasshopper
In order to see what mechanism would be optimal for Grasshopper, it is necessary to first list the different possible ways in which components may wish to access and store data, and also how families of data points flow through a Grasshopper network, often acquiring more complexity over time.
A lot of components operate on individual values and also output individual values as results. This is the simplest category, let's call it 1:1 (pronounced as "one to one", indicating a mapping from single inputs to single outputs). Two examples of 1:1 components are Subtraction and Construct Point. Subtraction takes two arguments on the left (A and B), and outputs the difference (A-B) to the right. Even when the component is called upon to calculate the difference between two collections of 12 million values each, at any one time it only cares about three values; A, B and the difference between the two. Similarly, Construct Point takes three separate numbers as input arguments and combines them to form a single xyz point.
Another common category of components create lists of data from single input values. We'll refer to these components as 1:N. Range and Divide Curve are oft used examples in this category. Range takes a single numeric domain and a single integer, but it outputs a list of numbers that divide the domain into the specified number of steps. Similarly, Divide Curve requires a single curve and a division count, but it outputs several lists of data, where the length of each list is a function of the division count.
The opposite behaviour also occurs. Common N:1 components are Polyline and Loft, both of which consume a list of points and curves respectively, yet output only a single curve or surface.
Lastly (in the list category), N:N components are also available. A fair number of components operate on lists of data and also output lists of data. Sort and Reverse List are examples of N:N components you will almost certainly encounter when using Grasshopper. It is true that N:N components mostly fall into the data management category, in the sense that they are mostly employed to change the way data is stored, rather than to create entirely new data, but they are common and important nonetheless.
A rare few components are even more complex than 1:N, N:1, or N:N, in that they are not content to operate on or output single lists of data points. The Divide Surface and Square Grid components want to output not just lists of points, but several lists of points, each of which represents a single row or column in a grid. We can refer to these components as 1:N' or N':1 or N:N' or ... depending on how the inputs and outputs are defined.
The above listing of data mapping categories encapsulate all components that ship with Grasshopper, though they do not necessarily minister to all imaginable mappings. However in the spirit of getting on with the software it was decided that a data structure that could handle individual values, lists of values, and lists of lists of values would solve at least 99% of the then existing problems and was thus considered to be a 'good thing'.
Data storage as the outcome of a process
If the problems of 1:N' mappings only occurred in those few components to do with grids, it would probably not warrant support for lists-of-lists in the core data structure. However, 1:N' or N:N' mappings can be the result of the concatenation of two or more 1:N components. Consider the following case: A collection of three polysurfaces (a box, a capped cylinder, and a triangular prism) is imported from Rhino into Grasshopper. The shapes are all exploded into their separate faces, resulting in 6 faces for the box, 3 for the cylinder, and 5 for the prism. Across each face, a collection of isocurves is drawn, resembling a hatching. Ultimately, each isocurve is divided into equally spaced points.
This is not an unreasonably elaborate case, but it already shows how shockingly quickly layers of complexity are introduced into the data as it flows from the left to the right side of the network.
It's no good ending up with a single huge list containing all the points. The data structure we use must be detailed enough to allow us to select from it any logical subset. This means that the ultimate data structure must contain a record of all the mappings that were applied from start to finish. It must be possible to select all the points that are associated with the second polysurface, but not the first or third. It must also be possible to select all points that are associated with the first face of each polysurface, but not any subsequent faces. Or a selection which includes only the fourth point of each division and no others.
The only way such selection sets can be defined, is if the data structure contains a record of the "history" of each data point. I.e. for every point we must be able to figure out which original shape it came from (the cube, the cylinder or the prism), which of the exploded faces it is associated with, which isocurve on that face was involved and the index of the point within the curve division family.
A flexible mechanism for variable history records.
The storage constraints mentioned so far (to wit, the requirement of storing individual values, lists of values, and lists of lists of values), combined with the relational constraints (to wit, the ability to measure the relatedness of various lists within the entire collection) lead us to Data Trees. The data structure we chose is certainly not the only imaginable solution to this problem, and due to its terse notation can appear fairly obtuse to the untrained eye. However since data trees only employ non-negative integers to identify both lists and items within lists, the structure is very amenable to simple arithmetic operations, which makes the structure very pliable from an algorithmic point of view.
A data tree is an ordered collection of lists. Each list is associated with a path, which serves as the identifier of that list. This means that two lists in the same tree cannot have the same path. A path is a collection of one or more non-negative integers. Path notation employs curly brackets and semi-colons as separators. The simplest path contains only the number zero and is written as: {0}. More complicated paths containing more elements are written as: {2;4;6}. Just as a path identifies a list within the tree, an index identifies a data point within a list. An index is always a single, non-negative integer. Indices are written inside square brackets and appended to path notation, in order to fully identify a single piece of data within an entire data tree: {2,4,6}[10].
Since both path elements and indices are zero-based (we start counting at zero, not one), there is a slight disconnect between the ordinality and the cardinality of numbers within data trees. The first element equals index 0, the second element can be found at index 1, the third element maps to index 2, and so on and so forth. This means that the "Eleventh point of the seventh isocurve of the fifth face of the third polysurface" will be written as {2;4;6}[10]. The first path element corresponds with the oldest mapping that occurred within the file, and each subsequent element represents a more recent operation. In this sense the path elements can be likened to taxonomic identifiers. The species {Animalia;Mammalia;Hominidea;Homo} and {Animalia;Mammalia;Hominidea;Pan} are more closely related to each other than to {Animalia;Mammalia; Cervidea;Rangifer}** because they share more codes at the start of their classification. Similarly, the paths {2;4;4} and {2;4;6} are more closely related to each other than they are to {2;3;5}.
The messy reality of data trees.
Although you may agree with me that in theory the data tree approach is solid, you may still get frustrated at the rate at which data trees grow more complex. Often Grasshopper will choose to add additional elements to the paths in a tree where none in fact is needed, resulting in paths that all share a lot of zeroes in certain places. For example a data tree might contain the paths:
{0;0;0;0;0}
{0;0;0;0;1}
{0;0;0;0;2}
{0;0;0;0;3}
{0;0;1;0;0}
{0;0;1;0;1}
{0;0;1;0;2}
{0;0;1;0;3}
instead of the far more economical:
{0;0}
{0;1}
{0;2}
{0;3}
{1;0}
{1;1}
{1;2}
{1;3}
The reason all these zeroes are added is because we value consistency over economics. It doesn't matter whether a component actually outputs more than one list, if the component belongs to the 1:N, 1:N', or N:N' groups, it will always add an extra integer to all the paths, because some day in the future, when the inputs change, it may need that extra integer to keep its lists untangled. We feel it's bad behaviour for the topology of a data tree to be subject to the topical values in that tree. Any component which relies on a specific topology will no longer work when that topology changes, and that should happen as seldom as possible.
Conclusion
Although data trees can be difficult to work with and probably cause more confusion than any other part of Grasshopper, they seem to work well in the majority of cases and we haven't been able to come up with a better solution. That's not to say we never will, but data trees are here to stay for the foreseeable future.
* This is not something we hit on immediately. The very first versions of Grasshopper only allowed for the storage of a single data point per parameter, making operations like [Loft] or [Divide Curve] impossible. Later versions allowed for a single list per parameter, which was still insufficient for all but the most simple algorithms.
** I'm skipping a lot of taxonometric classifications here to keep it simple.…
Added by David Rutten at 2:22pm on January 20, 2015
large scale prototyping techniques. The programme continues to build on its expertise on complex architectural design and fabrication processes, relying heavily on materiality and performance. Autumn DLAB brings together a range of experts – tutors and lecturers – from internationally acclaimed academic institutions and practices, Architectural Association, Zaha Hadid Architects, among others.
The research generated at Autumn DLAB has been published in international media – ArchDaily, Archinect, Bustler – and peer-reviewed conference papers, including SimAUD (Simulation in Architecture and Urban Design), eCAADe (Education and research in Computer Aided Architectural Design in Europe).
Autumn DLAB investigates on the correlations between form, material, and structure through the rigorous implementation of computational methods for design, analysis, and fabrication, coupled with analog modes of physical experimentation and prototype making. Each cycle of the programme devises custom-made architectural processes through the creation of novel associations between conventional and contemporary design and fabrication techniques. The research culminates in the design and fabrication of a one-to-one scale prototype realized by the use of robotic fabrication techniques, with the aim of integrating of form-finding, material computation, and structural performance.
The programme is structured in two stages:
PART 1 – participants are introduced to core concepts of material processes, computational methods and digital fabrication techniques. Basic and advanced tutorials on computational design and analysis tools are provided. The programme performs as a team-based workshop promoting collaboration, research and ‘learning-by-experimentation’.
PART 2 – participants propose design interventions based on the skills and knowledge gained during phase 1 and supported by scaled study models and prototypes. The fabrication and assembly of a full-scale architectural intervention with the use of robotic fabrication techniques will then unify the design goals of the programme.
Applications
1) A limited number of 10 places are available. To apply, please send a small portfolio (5MB) to the Visiting School Office.2) PARTIAL SCHOLARSHIPS ARE AVAILABLE. Please send a letter of intent and a small portfolio (5MB) to the Visiting School Office.3) As this programme has a limited number of places it requires a selection process, if you are offered a place on programme, the Visiting School Office will inform you of how you can complete the registration process.
The deadline for applications is 13 AUGUST 2021.
Eligibility
The workshop is open to current architecture and design students, PhD candidates and young professionals. Software Requirements: Adobe Creative Suite, Rhino 6. No prior knowledge of software tools is required for eligibility.
Fees
The AA Visiting School requires a fee of £975 per participant, which includes a £60 Digital Membership fee.Students need to bring their own laptops, digital equipment and model making tools.
…
umbers behave differently from the reals, in that when they are squared they give a negative result. They are written as multiples of the imaginary unit i, which is defined so that:
i*i=-1
Complex numbers are numbers which have two parts (hence the name complex) - a real part and an imaginary part.
For example:
3+4i,
or more generally:
a+bi, where a and b are some real numbers.
Well that's a definition, but I guess you might be wondering what is the point of them - I've not said anything yet about why they are interesting and useful...
Solving cubic equations was one of their first uses, but I doubt that is what most of you are interested in.
Where they really get fun is when you start looking at them geometrically.
The Argand plane is a setting that allows us to treat complex numbers a bit like vectors.
Each complex number a+bi defines a point relative to an origin (0,0), much the same as a vector with an x and y component.
Like vectors we can add and subtract them to get a new point.
But when we multiply them, unlike vectors, we add the angles (measured anti-clockwise from the positive real axis, also called the argument) and multiply the lengths (or the modulus of each number).
This all follows naturally as a consequence of the definition of i as the square root of minus one.
........
That is just dipping a toe into the great depths.
Complex number math, and in particular complex Analysis (calculus with complex numbers) is a vast subject that I obviously can't cover much of here.
If you are interested in learning more :
The Math department at Cal State Fullerton has some very nice Complex Analysis pages.
Chapters 5 and 6 of the film Dimensions covers complex numbers very visually. You can watch it online here, or read the description here.
Complex numbers on Wikipedia
on MathWorld
Hans Lundmark's complex analysis pages
The book Indra's Pearls is about making certain types of fractals with complex numbers, and includes a good introduction, along with lots of pseudocode.
To really engage with some of the true depth and power of complex numbers I particularly recommend the beautiful Visual Complex Analysis. This was the book that made me love this subject.
I'm really looking forward to seeing more designers make use of complex numbers. I think it is a wonderful tool. It is an advanced branch of mathematics, requiring some serious study to understand, but because of its strong geometric connections, I think relatively accessible to those who tend to think more visually. Now that David has included them in Grasshopper, starting to explore them should be easier than ever.…
Added by Daniel Piker at 4:38am on November 25, 2009
can work in any node of a given hierarchy tree (loaded in your work session) by making the node "active". "Nodes" can be other things as well (like workplane, clip definitions etc).
Why to do that weird thing? Well, think any design being "flat" > meaning that all objects are placed in a single file (and in a single layer). Not that good > although the items are present you barely can handle them (because power is nothing without control, he he).
Let's go one step further: we can start classifying objects in "groups" (like a directories/files organization in any O/S). This means, in MCAD speak, creating assemblies (a void thing kinda like a directory) that contain components/entities (kinda like files).
Several steps further we end up with severely nested "arrangements" of entities (an assembly could be parent of something and child of something else).
For instance, it could be rather obvious the logical classification of a "geodetic" (so to speak) structure like this : a 40000m2 "hangar" defining some thematic park.
I mean : a void master that owns 4 equal void segment sets that own 4 "legs" that own various geodesic structural members + cables + membranes + you name it etc etc.
Each "leg" owns the concrete base (Shared) and a rather complex set of objects.
Notice that some tensile membrane "fixture" combos (see above)...act as perimeter light fixtures as well...meaning that the membrane tension plate may could be a child of a void "light" parent...or may could be a "stand alone" assembly etc etc.
These arrangements can be internal (belonging in, say, a x node within the current active file) or external (belonging in a y node within another file). If they deal with the same (topologically speaking) object they define clusters of Shared entities (or variations)- where only the view transformation matrix changes (in the simple scenario, he he). For instance the disk shown above is a Shared Assembly that owns the bolts, the plates, the tension member etc etc. Selective Instancing allows modifying some attributes without affecting the topology (i.e. the geometry).
The whole (terrible) mess is controlled by some tree like "dialog" (in Catia is "transparent") that is called Structure Browser. By controlled I mean (1) display/display mode with regard any tree member combo/selection set (assembly and/or component) in any View (2) clip state control (3) active status (for modifications/variations) (4) workplane control (5) drag and drop ownership control (6) ....
Now...what if I would chan…
this occasion, but it could be converted for DT in no time). Requires some minutes more as regards ... some things, but the usual update is due to some days.
Bad news: it's C#
Good news: User's Manual :
1. That thing (the C#, not me) after sorting (in a "sequential way", so tho speak) the panels (their order was chaotic) allows you to start the massacre by locating a focus of interest (and the user controllable +/- Range derived from it).2. The Range is variable (obviously) and takes care not to exceed the indices of the panel list (OK, that's elementary).
3. If you click the right button (Sadistic Q: where is it? he he) things are deleted and a new constantly self-updating list is your new List. Thus the massacre of panels is totally controllable. An autoZoom thing is also included (free of charge, but it's a bit nerve braking). Zoom factor is variable as well.
4. Then you move over (via the index slider) and start the massacre again. Notice the change of Range.
5. If you turn begin to false (initialization) and then begin to true > start all over again.
6. The other C# thing allows you to increment the index slider in a rather more convenient way. It's a bit weird: it uses delegates (A delegate is an object that knows how to call a method) and events (An event is a construct that exposes just the subset of delegate features required for the broadcaster/subscriber model - but don't ask what this means, he he) in order to talk with your slider (with a defined NickName) and perform the required value control.
NOTE: without realizing it you've just (indirectly) asked one of the most important questions even exposed in this Noble Forum. I hear you : what question? Well ... wait some days for the mother of all threads: "Total control in collections on a per Item basis"
may the Force (the dark option) be with you (and me)
best, Peter…
Rubicon (ii.e. some programming language [I would strongly recommend C#] > the Dark Side > years of pain + tears > hell or heaven?).
Back to that pile or worms of yours (I hate "simple" cases, he he).
0. if you want rounded lips ... Styrofoam is the only solution (+ sanding [buy a mask and some decent cigars ... path is long and hilly]). if not > goto 5/6.
1. by what means you think that you can shape Styrofoam? Do you have access to some CNC foam cutter? Or the only tools that you have are ... 2 hands and a knife? (or a thermal cutter). Accuracy is a BIG issue here: chances are that panels won't "fit". Solution is available in the forthcoming V3.
2. male "protrusions" on Styrofoam is kinda 3rd marriage > AVOID at any cost > this would end up in tears.
3. female ones are safe ... thus we need a proper "insert stripe" that must be compatible with the Styrofoam adhesive and strong enough to hold the pieces until the glue cures (it takes time, there's no instant Styrofoam adhesives around). Maybe aluminum (hard to cut by hand) or balsa (very expensive) or plywood (best option).
4. Some CNC foam cutters they can't shape the female "crevices" > be prepared (a thermal tool may(?) cut the mustard).
Note: panels made with Styrofoam look miserable because reality and theory differ. They also look miserable as well (and kitsch and miserable).
5. making the panels with (marine) plywood ... well this yields far superior accuracy and therefor aesthetics but (a) yields max panel thickness constrains, (b) introduces max panel dimensions constrains (c) yields packing issues [waste material] and (d) requires a totally different "connection" approach: it doesn't make sense to do some female crevice ... unless the plywood is very thick (expensive + heavy).
Note: Designing (pro option) self supporting "rib" reinforced sandwich composite panels ... well this is a bit far and away from what you can handle at present time.
So ... I've suspended the male/female thingy until you decide the final policy: it's the material/detailing that should dictate the method(s) AND the whole design and not the other way.
This is what we call bottom-top design approach (dinosaur Architects follow the top-bottom: disastrous + naive + naive + naive + avoid).
6. Plan ZZTop: make a stand alone autonomous perimeter frame per panel (marine plywood: imagine "thickening" these abstract beams shown inwards per panel) then join these frames by means of bolts (easy) and fill the "gaps" with Styrofoam (hmm). Note: you can reinforce the frames by a variety of means (say: a secondary "beam" sub-structure) achieving a rather elegant all overall solution.
This is the best solution by roughly 666 miles.
…
able all the components from that group.I know it's slowing down a lot, but the rhino performance is really poor on layouts. In Rhino 6 WIP it's a lot better though.
For the issue with different amount of drill holes i made an example script, how i would go for a solution to this. It's just a suggestion.
1) Do a little script that catches those holes and bake them to a separate layer.In my example i just generated them with GH.
2) Use RhinoCount (is installed with FabTools) to name the curves in Rhino by clicking one after the other. But first diable the layers, with the other geometry, so you don't accidentally click on geometry which you don't want to count.
You have 2 counters 1 for the part the second for the holes on each object. Increment the object counter if you have counted all holes of 1 object. By clicking on each hole the counter increments all by itself. Take a look at this command!
1 Click creates 1 Dot and renames the Rhino object. You can turn on/off all specific features of RhinoCount with the checkboxes. (see settings above)
And....this should be the result after some clicks:
3) If counted, you can reference the counted geometry again to GH with the counting as Datatree. (See attached GH File).
Then estimate the maximum amount of holes on one object in your drawing.Create a template with the amount of detail views and do the process from the layout tutorial again. For all objects with less holes you will have to delete the detail view which didn't have a target point or you do a sort of grouping for the hole centers and estimate the center of that group. You can be creative ;-)
I hope this helps. Good Work,
FF…
Added by Florian Frank at 7:49am on January 21, 2016
16-20 / PUEBLA JULY 23-27
This workshop is intended primarily for architects and designers interested in learning parametric and generative design applied to the generation and rationalization of complex geometries for their implementation in different design processes. The course will cover basic concepts and methodology to address many design issues through the development of algorithmic tools via a visual programming language and the development of digital fabrication schemes. Rhinoceros 3D and Grasshopper are going to be used as our modeling tools and V-Ray as our rendering engine. Monday to Friday from 10am to 2pm and from 4pm to 8pm 40hrs.
No previous knowledge of Rhinoceros 3D or programming required, CAD background desirable.
Students: 4,000 MXN Professionals: 5,000 MXN Info: workshop@3dmetrica.com 044 55 28790084 www.3dmetrica.com
www.facebook.com/3dmetrica
TALLER DE VERANO ARQUITECTURA PARAMETRICA DISEÑO GENERATIVO RHINO + GRASSHOPPER + V-RAY
TOUR MÉXICO 2012
MEXICALI 25 AL 29 DE JUNIO / CIUDAD DE MÉXICO 2 AL 6 DE JULIO / MORELIA 9 AL 13 DE JULIO / GUADALAJARA 16 AL 20 DE JULIO / PUEBLA 23 AL 27 DE JULIO
Este taller está dirigido principalmente a arquitectos y diseñadores interesados en el aprendizaje del diseño paramétrico y generativo aplicados a la generación y racionalización de geometrías complejas para su implementación en diferentes procesos de diseño. En el curso se abordarán los conceptos básicos y metodología para hacer frente a diversas problemáticas del diseño mediante el desarrollo de herramientas algorítmicas a través de un lenguaje de programación visual y el desarrollo de esquemas de fabricación digital. Se utilizarán Rhinoceros 3D y Grasshopper como herramientas de modelado y V-Ray como motor de renderizado. Lunes a Viernes de 10am a 2pm y de 4pm a 8pm 40 hrs.
No se requieren conocimientos previos de Rhinoceros 3D ni de programación, conocimientos previos de CAD deseables.
Estudiantes: 4,000 MXN Profesionales: 5,000 MXN Info: workshop@3dmetrica.com 044 55 28790084 www.3dmetrica.com
www.facebook.com/3dmetrica
…
rera de Arquitectura CEM | presenta la cordial invitación al Curso de Diseño Computacional a realizarse en nuestros laboratorios de Arquitectura y Diseño Industrial del Campus Estado de México.
Fecha: jueves 21, viernes 22 de 18: a 22:00 Hrs y sábado 23 de 8:00 a 15:00 Hrs febrero 2013. 15 Horas.
El taller está orientado a estudiantes y profesionales de la Arquitectura, Arte, el Diseño e Ingeniería.
COSTO:
Alumnos Tec o EXATEC con una cuota de $2000.00 pesos.* Estudiantes EXTERNOS y profesores TEC $3000.00*, Estudiantes de posgrado externos $3800.00* y Profesionales externos $4250.00 pesos.*
OBJETIVO GENERAL:
Alfabetización sobre lectura y escritura de herramientas computacionales para el desarrollo de la Arquitectura, Diseño e Ingeniería.
Objetivos específicos:
1. Comprenderá los conceptos metodológicos del Diseño Computacional y generativo.
2. Aplicará las metodologías en el diseño, análisis y despiece de una cubierta (celosía, muro, losa, fachada o mobiliario) con base en un espacio existente en el campus.
3. Desarrollará los conceptos de programación orientada a objetos (POO Intermedia)
4. Generará algoritmos y análisis en Grasshopper sobre el ejemplo de praxis.
5. Desarrollo de documentación y presentación de resultados.
6. Fabricación del objeto, escala por definir.
Requisitos: Conocimiento de alguna plataforma CAD/CAM/CAE.
Profesor:
Arq. David Hernández Melgarejo.
http://bioarchitecturestudio.wordpress.com
Mayor información:
Kathrin Schröter, Dipl.-Ing./Arch. (D)
Directora de la Carrera de Arquitectura e Ingeniería Civil
Escuela de Diseño, Ingeniería y Arquitectura
Campus Estado de México
TEC DE MONTERREY
Tel.: (52/55) 5864 5555 Ext. 5685 o 5750
Enlace intercampus:80.236.5685
Fax: (52/55) 5864 5319
kschroter@itesm.mx
www.itesm.mx
…
ou will see all of the available components on a ribbon at once so there is no need to keep clicking drop down menus.
It's all about discoverability with GH. What if you're a beginner and don't know about the Create Facility (dbl click canvas) how can you find Extr?
Even if you hover over every component or use the drop down lists you will not see the name Extr appear anywhere.
Sure it makes sense that Extr is short for Extrude but it's also the Nick Name of Extrude to Point component
So you can easily miss the fact that one has a Distance Input verses a Point Input.
I think I made the move to Icons around about the move from version 0.5 to 0.6, possibly before. I initially thought that I would go back to text because I loved the mono chromatic look of the text but I soon realised that Icons were the way forward. The greatest benefit is speed. You don't need to digest and decipher every component (which is written 90 degrees to the norm).
I'm not saying you should move to Icons forthwith but at least consider that once you have a better knowledge and understanding of GH, Icons will set you free.
My top ten tips that I would highly recommend to anyone wanting to better themselves with GH.
1) Turn on Draw Icons
2) Turn on Draw Fancy Wires
3) Turn on Obscure Components
4) Use the Create Facility like a Command Line eg "Slider=-1<0.75<2" or "Shiftlist=-1"
5) Use Component Aliases to customise your use of the Create Facility eg giving the Point XYZ component an alias of XYZ will bring it up as the first option on the Create Facility as opposed to the other possibilities.
6) Try to answer other people's questions even if it's not relevant to your own area. By looking into solving a problem outside of your comfort zone and then posting your results it is very rewarding but it also lets you see the other approaches that get posted in a new light.
7) Take the time to understand Data/Path structures.
8) Buy a second monitor - There is nothing that can compare to real estate when working in Grasshopper.
9) Read Rajaa Issa's Essential Mathematics
10) Pick a panel in a tab on the ribbon and get to know every component inside and out and then move on. Start with the Sets Tab > List Panel…