I tell you what I had to do and how I did it.
I have the following situation. A urban context with a square plot 40m x 40m surrounded by buildings.
If I extrude the plot I get 4 surfaces and I need to calculate the minimum daily quantity of direct sunlight hours each test point receives in the period from 22nd of April to 22nd of August. For example for the test point at index 21 of surface with index 1 (I am just creating these numbers in my mind) the minimum is on 27th of April and the test point receive 8 hours (this is also invented for the sake of the example) of direct sunlight. All the other days it receives more. So the values I have to found are these minimums for all the test points. Now how to calculate these minimum quantities is a different issue of the topic of this post and actually I manage it.
Continuing with the explanation of what I had to... so I have only the initial plot that generate 4 surfaces, then I want to test smaller plots generated by an offset of 4 m of the original one, and the relative 4 surfaces for each smaller plot.
So in this case I think I cannot use your suggestion because the object don't exist yet.
I managed creating a loop with Anemone, the loop generate an offset starting from the original at 0 until 4 (then I multiply it by 4 to obtain the offset at 0, 4, 8, 12 and 16. Then I did like you also suggest I record every time the result with the DataRecorder and I create for each result a different branch with the index coming from the loop (0, 1, 2, 3 and 4) with the Flatten component.
In this image you can see all the surfaces saved in the same way as described above and in white the test points that receive minmum or equal than 2.5 hours per day of direct sunlight in the period from from 22nd of April to 22nd of August and in dark gray the test points that receive less.
The main point of this discussion is just the fact that instead use this tricky way I used, or the one you suggest, to analyze separately (because they shade each other) 20 geometries (in this case 20 they could be many more) it would be good if it would be possible just to input all the geometries at the same time and they would not shade each other so to get directly all the results with one run and in a more simple way.
Francesco
…
思った感じになりません。
balls の代わりにplanarカーブを直接入れてみましたがエラーが出ます。
ファンクションにしてみたところ、forループので作った数値が反映されていません。
ファンクションのインスタンス?を出力していないと思い上記のようにしましたがエラーが出てしまいます。
以上の事から自分の認識が正しいのかよくわからなくなりました・・・
python自体の深いところをわかっているわけではないので余計こんがらがりました。
そこで、for b in ballsはどのような条件または使い方であれば使えるのでしょうか?
そして、上記のように別のオブジェクトに対しての使い方はどのようにすればできるのでしょうか?
2:同じファンクション内のdist = rs.Distance(self.pos,b.pos)についてですが
この文章も for b in balls によってbはBallのインスタンスであると定義?されたためb.posがbの位置であると分かるのでしょうか?
pythonは定義しなくても動いてしまうのでどのような時に使えるのか文章見ただけではよくわかりません・・・
大変細かいことかもしれませんが、よりpythonをしっかりと理解するためにも、どなたかわかる方ご教授いただけると幸いです。…
lla progettazione parametrica e le tecniche di modellazione algoritmica per la generazione di forme complesse
___________________________________________________________________________________
luogo:
Sala meeting Hotel Mercure Milano Centro Piazza Oberdan 12 – 20129 MILANO
Scadenza iscrizioni: 12 Novembre 2011 – ore 15.00
___________________________________________________________________________________
info e prenotazioni:
Le Penseur (coordinamento formazione)
info@lepenseur.it
081 564 21 84
347 548 71 78
quote di partecipazione e programma (formato PDF)
ulteriori informazioni sui corsi PLUG > IT
___________________________________________________________________________________
PROGRAMMA DEL CORSO
GIORNO_01
10.00 – 10.30: presentazione workshop
10.30 – 11.30: introduzione alla progettazione parametrica: teoria, esempi, casi studio
11.30 – 13.00: Grasshopper: concetti base, logica algoritmica, interfaccia grafica
13.00 – 14.00: break | lunch
14.00 – 16.00: nozioni fondamentali: componenti, connessioni, data flow
16.00 – 18.00: esercitazione
GIORNO_02
10.00 – 12.00: funzioni matematiche e logiche, serie, gestione dei dati
12.00 – 15.00: analisi e definizione di curve e superfici
GIORNO_03
10.00 – 12.00: definizione di griglie e pattern complessi
12.00 – 13.00: trasformazioni geometriche, paneling
13.00 – 14.00: break | lunch
14.00 – 16.00: esercitazione
16.00 – 18.00: attrattori, image sampler
GIORNO_04
10.00 – 13.00: data tree: gestione di dati complessi
13.00 – 14.00: break | lunch
14.00 – 15.00: digital fabrication: teoria ed esempi
15.00 – 18.00: nesting: scomposizione di oggetti tridimensionali in sezioni e posizionamento su piani di taglio per macchine a controllo numerico CNC…
ied away on lunch break...
1 - Clean up the mesh a bit: Lots of ways to do this, but as a rule of thumb, it's probably best to clean the mesh as best you can before bringing into GH. But, for the sake of example...a basic method is comparing the normal of a face to a Z Vector, and if the comparison results in a match, within some tolerance...then you can get rid of it. When dealing with topography and slope, the common unit of measure is generally percent, but to start with, we can use degrees.
2 - Evaluate MeshFaceNormals: similar to step 1, you are simply getting the normal vector of a face, and comparing it to a Z vector. The important thing to note is that the Vector Compare component outputs radians. At this point, you need to either convert to degrees again, OR, do some math and convert to percent.
3 - Set Slope Zones and Ranges : There are a few ways to do this, but I think this is one of the most straight forward methods. Set your "slope zones", create some consecutive domains from those numbers, then just find the values that fit into those domains, (you have the values from step 2, so you can pump those into the N input of the Find Domain component.)
4 - Color Mesh by Slope Value : the gradient component is setting colors based on your slope range domains. Because you have input a list of domains, (0 to 10, 10 to 20 , 20 to 25, 25 to 40, and 40 to 60), the Find Domain component is actually just putting the slope values into the corresponding range, and then outputting the index number of the slope domain, (0,1,2,3,4). The gradient component then maps those 5 numbers, (0-4.....which is actually 5 numbers because list counts start, and include, 0), to 5 colors.
4a - NOTE: The gradient component needs a Lower limit, and Upper Limit. In this case we start the lower limit at 0, (index of first slope range...0 to 10). The upper limit is the index of the LAST item in the Slope Zone/Range list, which is 4. I used a list length component to get the length of the below list, (which correctly returns 5 items....but I need the index of the last one, so the expression subtracts 1 from the length total).
0. 0.0 To 10.01. 10.0 To 20.02. 20.0 To 25.03. 25.0 To 40.04. 40.0 To 60.0
Then construct the mesh again using the cleaned vertices and faces from step 2, only adding in the new colors.
The last bit of the definition is just visualizing the slope value on the face...it's kind of overkill, but shown as an example.
…
Added by Chris Hanley at 1:55pm on January 8, 2016
iseño de proyectos a través de algoritmos mediante programación. Se explica el entorno de Grasshopper, se desarrollan diversos ejercicios. No es necesario conocimiento previo de Rhinoceros ni de programación.Total horas: 20 hrsFechas, Horario, Sede: Revisar la página de "Próxima Formación"Otros beneficios: 1) Un CD con: libreria de definiciones de Grasshopper desde herramientas simples hasta complejas y libros, tutoriales relacionados.2) 10% de descuento en los siguientes cursos o talleres que SEED | KRFR organicen.3) Posibilidad de unirte a SEED y a KRFR para hacer prácticas o para generar proyectos en conjunto.4) Se da un 10% de descuento en el licencia original de Rhinoceros.…
Added by ESTUDIO SEED at 2:41pm on January 17, 2011
rsi giornalieri (livello base) dedicati a 4 diversi topic Rhinoceros - 8 febbraio Grasshopper - 16 febbraio Rhino cam - 8 marzo Stampa 3D - 9 marzo
tutor: Amleto Picerno Ceraso, Francesca Viglione, Gianpiero Picerno Ceraso.
. Arduino for interaction (livello base-medio) 15, 16 marzo Il workshop parte dalle basi della programmazione di arduino fino ad arrivare all’interazione tra un oggetto fisico ed un imput informativo tutor: Gianpiero Picerno Ceraso
. Grasshopper advanced: “Complex surface” (livello medio) - 18, 19, 20 marzo Il workshop ha come obiettivo lo sviluppo di superfici complesse rispondenti ad informazioni provenienti dall’ambiente. Il corso parte dalle nozioni di Grasshopper fino ad arrivare alla possibile realizzazione di un oggetto tramite le tecniche di fabbrizazione digitale. tutor: Amleto Picerno Ceraso nb: è richiesta una conoscenza base di Grasshopper
. Emotional design (livello alto) 23, 24, 25 marzo Il workshop verterà sull’acquisizione, registrazione e manipolazione di tali dati/emozioni tramite Grasshopper e il loro utilizzo per controllare i parametri del design di specifici oggetti che diventeranno quindi, essendo customizzanti con le specifiche emozioni dell’utente, istanze e memoria tattile di precise esperienze. tutor: Andrea Graziano nb: è richiesta una conoscenza base di Grasshopper
. Fabricated fashion (livello alto) 26, 27, 28, 29, 30 marzo Il tema del workshop verte sulle tecniche di progettazione digitale applicate al fashion. tutor: Luis e Elizabeth Fraguada nb: è richiesta una conoscenza base di Grasshopper
. Blender (livello alto) - 16, 17, 18 maggio tutor: Andrea Graziano
. Interaction design: Arduino + Grasshopper (livello medio) - 2, 3, 4 maggio Il corso ha l’obiettivo di indagare processi di interazione tra le persone e gli ambienti in cui vivono attraverso il responsive design. nb: è richiesta una conoscenza base di Grasshopper e Arduino. tutor: Amleto Picerno Ceraso del Mediterranean FabLab e Antonio Grillo del FabLab Napoli.
info su costi: http://www.medaarch.com/2765-il-nuovo-calendario-attivita-firmato-medaarch/
…
he original epw file. The next one contains your dataset. The dataset to be replaced needs to be contained in a csv file as attached. You can replace more data from the original file by addiing additional columns in that CSV and assiging the correct column number in the grasshopper file. The ordering of columns in an EPW file is shown in the last image. For example, Direct-Normal rad is column -21 and Diff-Horz rad is -20. All of this will be clearer once you check the attached gh file.:
By the way, that theory about diffuse radiation being 10-40% of direct does not really hold. In a place like Seattle, one can expect to go without seeing the sun for extended periods of time and only see visible radiation from the sky.
(PS: I am sure there are probably more elegant ways to do this..I just wrote it this way to check if it was at all possible to do this with grasshopper).
…
roposes now) definition is not quite right as stated above. From this link (sorry for that, but i'm lazy to look for a better one) we can see that:
The terms sky component and sky factor refer to the actual contribution of the sky to daylight, after considering both luminous distribution and incidence angle effects. There appear to be no hard and fast rules as to the type of sky distribution to be used with either term, however they are typically calculated using either the CIE Uniform Sky or CIE Overcast Sky to remove the dynamic effects of beam solar component.
After that the definition of VSc, as given by the BRE:
The Vertical Sky Component (VSC) is described by the UK Building Research Establishment (BRE) as the ratio of the direct sky illuminance falling on the vertical wall at a reference point, to the simultaneous horizontal illuminance under an unobstructed sky [Littlefair, 1991]. It also states that the Standard CIE Overcast Sky model is to be used for the sky illuminance distribution. This means that the reference value for the VSC percentage is effectively the unobstructed horizontal sky component.
And that's why i like a bit less the definition above (just sky component) and then generalizing the concept for all other possible surfaces.
As for SVF, doing a quick search of recent (relatively) sources that are trying to develop methodologies to define SVF they are based almost exclusively on solid/geometrical considerations. See these references for illustration:
Grimmond C.S.B., Potter S.K., Zutter H.N. and Souch C. 2001. Rapid Methods to Estimate Sky-View Factors Applied to Urban Areas. International Journal of Climatology. 21: 903–913 (2001). DOI: 10.1002/joc.659
Matuschek, O. Matzarakis, A. 2010. Estimation of Sky View Factor in Complex Environment as a Tool for Applied Climatological Studies. In: Matzarakis, A., Mayer, H., Chmielewski, F.-M. (Eds.), Proceedings of the 7th Conference on Biometeorology. Ber. Meteorol. Inst. Univ. Freiburg No. 20, 535-540.
Matzarakis A., Matuschek O. 2011. Sky view factor as a Parameter in Applied Climatology - Rapid Estimation by the Skyhelios Model. Meteorologische Zeitschrift, Vol. 20, No. 1, 039-045 (Open Access Article).
Hämmerle M., Gál T., UngerJ. & Matzarakis A. 2011. Comparison of Models Calculating the Sky View Factor Used for Urban Climate Investigations. Theoretical and Applied Climatology (2011) 105:521–527. DOI 10.1007/s00704-011-0402-3.
I know some other researches that use the term SVF just from its geometrical implications. This is probably because all those are based on site measurements or photographing.
It will be really interesting to calibrate those with the new LB component.
Thanks again,
-A.…
ble: Informing Digital Design with Real World Data
Information about each Workshop Cluster can be found here:
Cyber Gardens
Use the Force
Urban Feeds
Reflective Environments
Interacting with the City
Agent Construction
Authored Sensing
Performing Skins
Responsive Acoustic Surfacing
Hybrid Space Structure Typologies
The SmartGeometry 2011 Workshop will take place at CITA http://cita.karch.dk/
Applications to attend the SmartGeometry 2011 Workshop in Copenhagen will close next Monday 31st January 2011. General Conference registration will open within 1 month.
We hope to see you there!
****************************************************
Workshop 28th-31st March
Shop Talk 1 April
Symposium 2 April
Reception 2 April
These events follow the highly successful previous SG events in Barcelona 2010, San Francisco 2009, Munich 2008, New York 2007, Cambridge/London, UK 2006 and multiple preceding events.
Click here for more info...
BUILDING THE INVISIBLEInforming Digital Design with Real World Data
THE PREMISEVast streams of data offer a rich resource for designers. By incorporating external information into our design processes the autonomy of the design is challenged. User data, energy calculations, embedded sensing, material and structural simulation, human behaviour and perception, particle flows and force fields allows design to be situated and responsive. From the simulation of megacities to the solid modelling of material systems, design has the potential to be informed by the real. Design sits not separate from is environment but inhabits an ecological system, open, dynamic and interdependent, diverse, partially self-organising, adaptive, and fragile. Across scale and within time we now have the chance to instil architecture with an immanent intelligence creating new relationships between the user, the built and its ecosphere.THE OPPORTUNITYSystems theorists suggest that data is only a raw material. It can be differentiated from information, knowledge and wisdom. Understanding is multi-levelled: understanding of relations, understanding of patterns, understanding of principles. As digital designers our challenge is in harnessing the power of computation to assist us in informing our design process. Computers help us collect, manage and analyse the environment and inform us about an abundance of data. Our challenge is to use these inputs in a meaningful way to help us make better informed design decisions.THE AIMSG 2011 explores how the incorporation of real world data challenges existing design thinking. The SG 2011 workshop aim is to create physical prototypes of design systems to be exhibited in the SG2011 exhibition.
The SmartGeometry Group is a not-for-profit educational organization dedicated to the use of computational tools in architecture and engineering. SG brings professionals, academics, and industry together to explore the next generation of digital design. SG Workshops are non-platform specific, believing it is the methodology, not the tool, that matters.
…
Added by Shane Burger at 8:01pm on January 27, 2011
t of data it has to operate on. So only those aspects of the algorithm that differ in these cases are relevant.
For example if your algorithm always does exactly the same thing (let's say all it does is measure the size of an array and display it on screen) will be O(1), because it doesn't matter if you run it on an array containing 10 or 1000000 items. Measuring the size of an array is a constant-time operation:
Print(string.Format("Array contains: {0} element(s)", data.Length);
However if your algorithm works on not on arrays but on linked-lists, then it becomes an O(N) operation because counting all the elements in a linked list means you have to iterate over all of them. And the longer the list, the more iterations you need. In fact the number of iterations is exactly the same as the number of items. (ps. if you'd be using the System.Collections.Generic.LinkedList<T> class then it's still O(1), because apparently that particular implementation of linked lists caches the count and keeps it up to date.)
If you have a loop that runs for each item, and then inside that loop there is another loop that also runs for each item, then your complexity becomes O(N²). Or, in a similar case if your algorithm consumes two collections (N and M) and iterates over all items in N, and then inside that loop it iterates over all items in M, the complexity is O(N×M).
The case can be made that only the most severe complexity is relevant enough to report. For example if you have an algorithm that comprises of three steps, the first of which is O(log(N)), the second is O(N²) and the third is O(3ⁿ), then technically the total complexity would be O(log(N) + N² + 3ⁿ), however the first two parts are utterly insignificant compared to the third and therefore can be omitted entirely. Consider for example increasing the input size from 10 to 20 elements:
log(10) + 10² + 3¹⁰ = 1 + 100 + 59049 = 59150
log(20) + 20² + 3²⁰ ≈ 1 + 400 + 3486784401 ≈ 3486784802
As you can see the increase of the complexity is almost entirely due to the O(3ⁿ) portion, so much so that there's almost no point in mentioning the other two.
Now, your specific questions:
Constructors/declarations and method invokes are not necessarily O(1). In this particular case they are, but it is possible that some constructor you call may have a higher complexity. For example if instead of an empty List<T> you're constructing a SortedList<T> based on your inputs, then it definitely may be the most significant complexity in your entire algorithm and it needs to be taken into account.
Correct. A loop like this has complexity O(N), ignore stuff that only happens once like the declaration of the iteration variable.
I don't understand that line of code. cP is already a list. Why are you calling ToList() on it? In general making copies of memory-contiguous collections (like arrays or lists) can be done in O(1), depending on implementation, because blocks of memory can simply be duplicated or moved at one go using the correct hardware ops. However other times it will require a loop in which the complexity goes up.
It's very cheap to add items to lists, provided the list has enough space to add new items. By default a list is big enough to contain only 4 items. If you try and add a fifth one, the list will need to allocate more memory elsewhere, copy the 4 existing items into the newly allocated space and only then add a new item. So, if you know ahead of time how many items you'll be adding to a list (or even if you only know a theoretical upper bound), you should construct the list using that known capacity. This will speed up the process of adding many items to a single list.
Don't know how crypto providers work, but since this part of your algorithm does not depend on cp.Count or the magnitude of populationCount, it doesn't matter for the big-O complexity metric.
…