Programming.Architecture

Paul Coates

• Publisher: Routledge
• Year: 2010
• ISBN:
  9781136899041
• Edition: 1
• Topic: Architektur
• Subtopic: Architektur Allgemein

Programming.Architecture is a simple and concise introduction to the history of computing and computational design, explaining the basics of algorithmic thinking and the use of the computer as a tool for design and architecture.

Paul Coates, a pioneer of CAAD, demonstrates algorithmic thinking through projects and student work collated through his years of teaching students of computing and design. The book takes a detailed and practical look at what the techniques and philosophy of coding entail, and gives the reader many "glimpses under the hood" in the form of code snippets and examples of algorithms.

This is essential reading for student and professional architects and designers interested in how the development of computers has influenced the way we think about, and design for, the built environment.

chapter one
Rethinking representation

The introduction sets out the initial position of text as design representation. Fundamentally the proposition is that Chomsky’s dictum – that finite syntax and lexicon can nevertheless generate an infinite number of useful (well-formed) structures – can be applied to artificial languages, and that texts can be written in those languages to generate architectural objects, taken to mean ‘well-formed’ configurations of space and form. This is the generative algorithm and the idea is that a generative algorithm is a description of the object just as much as the measurement and analysis of the object, the illustration of the object and the fact of its embodiment in the world.

The position here is that the text we are looking at, being an artificial language, usually depends for its embodiment on some hardware – the engineering product of the Turing machine – and this hardware affords some species of representation, from simple graphics all the way up to programmable hardware, 3D printing and immersive virtual worlds. But this aspect is simply an unfolding of the underlying algorithm, which is still the original representation. It would be possible to orchestrate 300 human beings to obey instructions and so act out the algorithm (like synchronised swimmers) such as in the following.

Some simple texts

As a very first shot, take the example of representing some simple geometric shapes and volumes like the circle, the spheroid and other 3D polyhedra, not using geometry, but small programs written in a dialect of Logo (a venerable Artificial Intelligence (AI) language defined by Seymour Papert, whose history is elaborated in the next section).

Triangles and circles

For the 2D case, this can be verified with a simple experiment using a program with a large number of points in 2D space, initially sprinkled randomly over the plane.

Give each point a rule:

‘Search through all the other points and find the nearest one to yourself.’‘Then move away from this nearest point.’

All the points do this simultaneously.

Of course the problem is that, in backing away from your nearest neighbour, you may inadvertently come too close to someone else, but that is ok because then you just turn around and back away from them. Remember that everybody is doing this at the same time.

To demonstrate how this works we can teach these rules to a computer using the NetLogo language which provides a mechanism for setting up parallel computations very simply. The points are described using ‘turtles’ – little autonomous computer programs, all of whom obey the program set out below:

to repelask turtles[ set closest-turtle min-one-of other turtles [distance myself] set heading towards closest-turtleback 1]end

To understand this piece of code, first notice that the whole thing is wrapped up in the clause:

to repel do somethingend

This is because we are defining how to do something for the computer, so here we are setting out how to repel. The stuff between the word ‘to’ and the word ‘end’ is the actual code. Then comes the phrase ‘ask turtles’. Who, you might ask, is doing this asking? The turtles are the points in space, they are really a lot of tiny abstract computers, and the global overall observer is, in this statement, sending out a message to all the turtles to run the program enclosed in the square brackets [ ], which is the three sentences:

1) set closest-turtle min-one-of other turtles [distance myself]2) set heading towards closest-turtle3) back 1

The turtles are being told:

‘Dear turtles, I would like to ask you to look through all the other turtles to find the one whose distance away is at a minimum.’

Then they must remember which turtle this is by storing its reference in the name ‘closest-turtle’.

Now the turtles are told:

‘Set your heading so that you are pointing towards this “closest-turtle”, and back off one step.’

Interestingly we also have to tell the computer to address the ‘other’ turtles as in the human language description . If we just asked all the turtles this would include myself (the one doing the ASKing), and we would get a value of zero and try to walk away from ourselves – not a good idea. This is a good example (the first of many) of how we have to SPELL IT OUT for these supremely pedantic machines.

In the top left-hand image, the trails of the turtles are shown moving from the initial random sprinkling to the triangular grid. It takes about 500 steps for the system to settle down, and it can be observed that the turtles quite quickly find a suitable position and then stay there (the trails do not stretch very far, and rarely cross).

These and many other examples of programming in the book are based on NetLogo. This language is a descendant of StarLogo which, in turn, was a parallel implementation of Logo (described in the next chapter), which itself was a development of LISP (see Chapter 3). See Resnick (1994) for a good introduction.

The turtles settle down to a triangular least-effort configuration. See below where the points are linked to show the triangular grid.

To the left, two versions of the outcome running with links are shown. None of these patterns lasts for long; like all dynamic systems the moment can be captured, but is gone and lost for ever by the ceaseless jiggling of the turtles.

Emergent tessellations

With a suitable repel strength, the points all settle down in a triangular pattern because whenever they diverge from this grid they are in an unstable situation and will always fall back into the triangular lattice. The point to note is that these wiggles are not in the algorithm (all it states is the backing off principle outlined above). What would one expect from such an algorithm? At first sight perhaps just aimless wandering; however, it does in fact settle down as if pulled into alignment by some ‘force’ not implied by the two lines of code. This is an example of ‘emergence’ – the idea that the program, by operating continuously in parallel, engenders a higher order observation, which could be characterised as a simple demonstration of the principle that the triangular lattice is the least cost-minimum energy equilibrium point for a 2D tessellation, with each point equidistant to six others. Here also is our first example of an algorithm which possessed epistemic independence of the model (in this case the code of the repel algorithm) from the structural output running the algorithm. In other words the stable triangular tessellation (the structural output of the program) is not explicitly written in the rules; which is an example of distributed representation.

Distributed representation

This is also the first example of many that illustrates the notion of distributed representation. The way the algorithm works is to embed the rules to be simultaneously followed in EACH turtle. Each turtle (small autonomous computational entity) is running the little program described above with its own decision making – who is nearest to MYSELF – and behaves independently of the other little computers – I turn THIS WAY and back off. The repel algorithm is the only available description we can find in this system, everything else is just general scheduling events and general start stop for the whole simulation, and this representation is present in EVERY turtle. The turtles can interact with each other and have some limited observational powers, for instance they can ‘feel’ the nearest turtle and take appropriate action, but they do not know about the triangular tessellation since that can only be observed by the global observer – in this case, the person (you) running the simulation on your computer. This distinction between different levels of observer is a key aspect of distributed representation, and will crop up many times in the following pages. It is vital, with distributed representation models, that there is some feedback present between these little autonomous programs; if each one took no notice of its neighbours then nothing would happen. This is evident in the cellular automata shown next and the canonical ‘pondslime algorithm’ introduced at the end of this chapter.

It is instructive to compare this bottom-up small program with the conventional recipe for a triangular tessellation. Of course there are many ways of describing how to draw such a pattern by using a simple wallpaper approach.

Wallpaper algorithm

Set out a line of dots at a spacing of 1.Duplicate this line with an offset of 0.5 in the x direction and the square root of 0.75 in the y direction.Do this as many times as you like.

The square root of 0.75 is the height of an equilateral triangle of side 1 derived from Pythagoras (where height² + 0.5² = 1²; so h = √1-0.25), which evaluates to approximately 0.8660254037844386467637231 7075294. This is not a very attractive number and seems to suggest that this algorithm is not capturing the real description of the underlying dynamics, but just mechanically constructing a top-down and rather clumsy measurement of the outcome. This distinction should be remembered when simulations and modelling are discussed elsewhere, as it forms part of the argument in favour of the ‘short description’ encoded in the generative rule rather than the ‘long description’ involved in traditional geometry.

IFELSE is an example of one of the key concepts of any programming language: the ability to get the computer to ask a question about which there are a number of things to process. Known as a ‘conditional statement’, it has many forms, but in this language, in this situation, we use the phrase ‘ifelse’.

This construct example has to decide which of two possible routes to take in the flow of the program.

Cheesy illustration: If standing at a fork in the road, with the possiblity of going left or right, you need some way of evaluating the choices open to you. So there you are, what do you do? It happens you have a note from your aunt in your pocket, you take it out and it says:

{‘when reaching a fork in the road, if it’s after lunch turn left, else turn right’}

It is clearly just after lunch, so you take the left turn. Problem resolved. (The left turn takes you to the tea rooms, obviously.)

In the script of attract the note from your aunt is asking ‘if your distance to the centre is less than radius, then take a step back, o...

Table of contents

• Contents
• How to read this book
• Acknowledgements
• introduction
• chapter one Rethinking representation
• chapter two In the beginning was the word
• chapter three The mystery of the machine that invents itself
• chapter four Evolving the text – being even lazier
• chapter five Text of the vernacular
• chapter six Epilogue or rethinking representation (again)
• References
• Index and glossary
• Image credits