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.
…
d Design workshop is a two day intensive workshop, exploring the new KingKong plugin for Grasshopper. The software simuates curved folding, and offers simple attractor functions to modulate an array of folded panels on a surface. The focus will be on building simulations of folding inspired by physical folding, and the comtrol of complex arrangements of panels, which will be realised with the CraftROBO vinyl cutter.
Day 1 - AM: Material Computation - intuitive techniques for designing shapes foldable by robots
Day 2 - PM: Folding Design - digitise fold patterns and use the KingKong plugin to simulate folding, design arrangements of panels with the attractor system, using differnet grid types, using different surface types, fill/empty feature, live baking feature
Day 3 - AM: Fabrication Data - refining the design for fabrication, outputing data
Day 4 - PM: Panel Assembly - cutting on the CraftROBO vinyl cutter, assembly of components
Two more dates in April and May.
More details and booking on the RoboFold website:
http://www.robofold.com/index.php?WEBYEP_DI=18…
Loop'. The fun part of the slower version is that you can see what it's doing while it's running. 'Fast Loop' gives no indication that it's working, so you want to test it with small numbers and be sure it's coded properly before bumping the iteration count up.
The GH profiler running the slow version showed between 1 and 1.5 seconds per loop, but the reality was more like ~10 seconds per loop toward the end of an 11 X 11 grid, or ~20 minutes total. It's easier to be patient because you know it's working.
The 'Fast Loop' finished the same grid in 1.6 minutes! An impressive improvement. I've been running it on a 30 X 30 grid (900 points) for ~23 minutes so far and see nothing yet. Not the ~12 minutes I had hoped for... Now 36 minutes on this loop for 900 points... hope it's not stuck. Not fast! Later - DONE!! Profiler says 59 minutes for 900 points but it was more like an hour and twenty minutes total. It succeeded, I have a single 'Closed Brep' from 900 extruded rings, baked to Rhino.
Another strategy to explore would be doing 'SUnion' on a smaller grid using the Anemone loop, then replicate it by moving it as needed to form a larger grid; then run the copies through another 'SUnion' loop. I went ahead and implemented that while waiting. It works and is fast! Started with 3 X 3 and ran the result again as 5 X 5 (9 X 25 = 225 total) in barely ~70 seconds!? Trying 36 X 36 now... 1,296 points appears to have succeeded in less than ten minutes! Though it seems to take quite awhile after the loop ends before control is restored to GH/Rhino. I'll let you do your own experiments and benchmarks.
I encapsulated the loop in a cluster called 'suLoop' (blue groups).
Internal of 'suLoop' cluster:
…
Added by Joseph Oster at 11:14pm on March 22, 2017
the use of digital technologies as architectural design tools. The workshop " Computer Aided Design: parametric design and digital fabrication " aims to do some introductory teaching in the use of some of these tools.
The workshop will focus on the use of computational models of parametric behavior for generating architectural forms. The generative capacity of these models it will be tested in the development of designs defined by repetitive non-standard components, based on the parametric control of its variations and series differentiations. This process will be developed by the use of a three-dimensional modeling software - Rhinoceros, associated with an application for visual programming - Grasshopper.
The last day of the workshop is dedicated to the use of digital manufacturing tools in architecture. Part of the work will take place at the facilities of the Institute of Design of Guimarães (IDEGUI) providing for the use of their laboratories and manufacturing CNC machines (computer numerically controlled).
At the end of the workshop, it is intended the students to understand that the use of digital technologies in architecture can overcome representational functions, and their integration in the design conception, analysis and construction enriches the methodology of project development.
Terms & Participants
The workshop will take place at the School of Architecture of the University of Minho (Campus Azurém, Guimarães) and the Institute of Design of Guimarães (Couros, Guimarães).
The workshop is pointed at students who attend the 3rd year and 4th year from MiArq, EAUM.
The maximum acceptance is 20 students and a minimum of 10 students.
Deadline for entries is April 11 and must be performed by eaum.pac@gmail.com.
Program summary :
Day 23 April 14 -20h
Introduction to 3D modeling in Rhinoceros. Regular geometries, ruled surfaces and NURBS surfaces.
Day 30 April 14 -20h
Parametric design in architecture. Introduction to methods of visual programming.
May 1, 9 -13h 14 -18h
Development of a design idea by the use visual programming processes in Grasshopper.
May 2, 9 -13h 14 -18h
Introduction to methods of digital fabrication. Manufacture physical models of the proposals made.
It is expected that this meeting will take place in the IDEGUI labs.
team:
Bruno Figueiredo ( Lecturer, EAUM )
Paulo Sousa ( PhD candidate , EAUM )
Nuno Cruz ( Invited Lecturer , EAUM )
Cláudia Alvares ( 5th year MiArq student , EAUM )
Javier Bono ( 4th year MiArq student, EAUM )
João Amaro ( 5th year MiArq student, EAUM )…
si à faire le tri avec Grasshopper et l'outil Points in Brep, comme je pensais. Je suis passé d'environ 400 000 points à uniquement 20 000 points autour de mes 3 rails. C'est très efficace (mais un peu dangereux avec tous ces points).
J'ai interdit au composant CircleFit de faire un cercle, s'il n'y a pas au moins 5 points présents sur la section. Car lorsqu'il y a seulement 3 ou 4 points, il suffit qu'il y en ait un pour que le cercle soit faux, alors qu'au delà, le cercle a plus de chance d'être "bon".
J'ai également créé des "Pipe" (créés à partir de portions de l'axe) au lieu des "Box » de sélection des points pour éviter de sélection trop de points que ne serait pas des points du rail.
J'ai ensuite créé des « panel » pour la moyenne des distances en X et en Y et la moyenne des distances centre à centre.
Tout cela fonctionne bien avec un axe et un tuyau. Mais maintenant j'essaie d'appliquer ça à plusieurs rails en même temps. Je crois avoir compris qu'il faut créer des « path » dans l'imput manager, et faire correspondre le « path » de l'axe et celui du Tuyau.
Dans mon exemple j’ai mis 3 courbes et 21 sections. Au moment où j'utilise les boîtes pour créer les portions des axes, il crée 63 « sous-path » de 1 courbe alors qu'il faudrait qu'il crée 3 "paths" de 21 courbes, enfin si j'ai bien compris.
Car une fois qu’il a créé les points à l’intérieur des « Pipe », il doit les projeter sur les plans correspondant. Et c’est là que le problème se voit. Il ne fait pas correspondre les points à projeter et les plans.
Je vous envoie la version à une courbe et un tuyau (c’est la v5 avec un fichier rhino ou la courbe d'axe est "bakée" pour pouvoir faire un zoom sur la zone plus rapidement) et je vous envoie également, celle avec 3 courbes et 3 tuyaux. Sachant qu’il faudra également attribuer un rayon pour un des tuyaux et un autre rayon pour les deux autres.
Tout ça est bien compliqué, j’espère que je ne vous embête pas trop.
Merci d’avance.…
values as a list. so each new value would shift all other values down the list and knock the 20th one off.
There are so many great list functions in Grasshopper, but I can't figure out how to create a list from incoming values! couldn't find anything about it in the gh primer either...
Right now, each incoming value replaces the previous one and no list is created :(
Also, I would like to collect values from 6 sensors and be able to identify the sensor number and generation of value. Not sure how the paths work yet, but something like {0,4,17} would signify the 17th value from sensor #4.
any help would be greatly appreciated :)…
Added by Poonam Sharma at 5:48pm on February 6, 2011
firefly, it inspired us to take it one step further and build a custom UI to control Rhino and replace the OSC app - since it was created originally for DJ's. We're not ready for a public release yet, but since this is the forum where the idea was inspired, I wanted to open up a beta to a few of you guys to try it out and get some feedback on what it's like to control a 3D CAD program from a multi-touch screen. We probably only have room for 10 or 20 people right now, as we have a limit to the number we can add, but if you're interested in trying it out, shoot me a message!Or post here, and we'll figure something out!Oleg.…
t, you can see 6 (+) signs with what you can add (A,B,C,P,Q,R).
Let's say you add A = 90 and B = 50.
Now you can't add the third angle (cause its 180-(50+90) = C output).
What you can add at the moment is P,Q,R.
You choose to add P = 10.
There is no more a possibility to add Q and R.
All component outputs now give us the data.
2. Triangle with P,Q,R
When you zoom the component, you can see 6 (+) signs with what you can add (A,B,C,P,Q,R).
Let's say you add P = 15, Q = 20.
Now if you add R, the component's outputs all the angles and edge lengths.
If R > P+Q then component throws warning. (> or >= ?)
You cannot add A,B or C anymone.
3.Triangle with P,Q and C
When you zoom the component, you can see 6 (+) signs with what you can add (A,B,C,P,Q,R).
Let's say you add P = 15, Q = 20.
Now if you add C (angle), the component's outputs all the angles and edge lengths.
You cannot add A,B or R anymone.
To make it all easier, disable the possibility to internalize the data.
Tolerance issue... Maybe round the angles always to floor , with 0.1 precision ?
…
component I just used different components and GH tools to do the same - and this become part of my short paper submission for SimAUD 2016). My solution compares the height of the same points of different solar envelope and then chose the lowest one. I read about the improvement you are working on and it is good but I think it is not yet what I need (or how the solar envelope tool could be more complete).
What I need is a solar envelope that would guarantee on different facades with different orientations (the example I sent you) a certain amount of direct sunlight, say 4h per day in a given period for example all the month of June at 60°N. So to guarantee the south facing facade I should chose the vectors from 10 to 14. But these are not ok for all the other facades because in this timeframe the East and West facing facades get only 2 hours and the North get 0 hours.
So the fist step would be have the possibility to chose different sun vectors for different facades. For the example I did (the 4 hours in June at 60°N) the south facing facade would need from 10 to 14, the East facing for example from 8 to 12, the West facing facade from 12 to 16 and the North facing facade from 6 to 8 and from 18 to 20.
If I would chose a single longer time frame that could get all these hours, from 8 to 20 then the resulting solar envelope would result probably smaller than the sum of the four solar envelopes.
But this is not complete yet. I mean the use of different sun vectors on different facades. The reason is that for example when I chose the sun vectors from 8 to 12 for the four hours on the East facing facade how do I know that the sun hit on the facade in that time frame or maybe it is obstructed by surrounding buildings? Since the sun at 60°N (where I live) in June rise at around 3.15 then maybe for that specific facade the sun hit from 4 to 8 and not from 8 to 12.
I did an extreme case talking about 60°N and that maybe the sun hit on a facade at 4 instead than 12, but it is just to make understand the logic. My suggestion for a more advanced solar envelope it should be integrated with the Sunlight Hours tool of ladybug. So the input should not be the sun vectors because I don't know when the sun hit on the facade but the input should be just the desired number of hours and the possibility to specify different number of hours for each facade. Then this last component that sum different solar envelope (I didn't use it yet but I understood what it does) should be integrated yes so the result would be one single solar envelope more likely using the lowest points (the highest I don't understand what for).
Let me know what you think!
…
300895
FB: https://www.facebook.com/ChidoStudio
FB: https://www.facebook.com/WEDOTdesign
Detalles:
Instructores:
Arturo de La Fuente (Chido Studio Argentina)
Eliana Monaco (Chido Studio Argentina)
Luis de La Parra (Chido Studio Mexico)
WS ROSARIO
Lugar:
DOSCASAS
ROSARIO: Sarmiento 1232 Planta Alta (2000 Rosario)
Fechas:
Viernes 16 de Mayo 2014 – 11:00 – 19:00 hs
Sábado 17 de Mayo 2014 – 11:00 – 19:00 hs
Domingo 18 de Mayo 2014 – 11:00 – 19:00 hs.
WS BUENOS AIRES
Lugar:
GARAGELAB
BsAs: Roseti 1380 CABA
Fechas:
Jueves 22 de Mayo 2014 – 18:00 – 21:00 hs
Viernes 23 de Mayo 2014 – 18:00 – 21:00 hs
Sábado 24 de Mayo 2014 – 11:00 – 20:00 hs.
Domingo 25 de Mayo 2014 – 11:00 – 20:00 hs
Importante:
Todos los niveles de experiencia son bienvenidos el único requisito es tener un entendimiento básico de los programas CAD y una actitud positiva hacia el aprendizaje de dichas herramientas. Necesitas llevar una laptop, nosotros te instalamos los programas de prueba.
Si planeas venir de fuera de la ciudad avísanos y te pondremos en contacto con otras personas que también vayan a hacerlo para en caso de desearlo puedan compartir su lugar de estancia.
Al participar en el workshop obtienes el 50 % de descuento en la licencia educacional Rhinoceros por medio de Rhino Chile.
COSTOS:
Profesionales: $1600
Estudiantes: $1400
Si ya realizaste algún Workshop de Chidostudio tenes un 20% descuento en esta inscripción.
Si venis en grupo con 2 amigos más cada uno tiene un %20 de descuento.
Proceso de Inscripción:
El participante deberá un mail a bsas@chidostudio.com donde se le enviará el procedimiento y medios de pago.
El depósito mínimo para reservar la matrícula es del 50% el resto deberá ser cubierto el día del evento.
Una vez que el depósito se haya llevado a cabo el participante deberá enviar a este correobsas@chidostudio.com los siguientes datos:
Nombre completo
Email
Teléfono
Institución educativa u Oficina
Archivo adjunto del recibo del depósito bancario
En cuanto recibamos la información immediatamente nos pondremos en contacto para especificar los pasos a seguir.
Contacto:
Arturo de La Fuente
bsas@chidostudio.com
Tel: (+54) 11-57268799
…