The circle that danced: The story of Pi

Madhava was a troubled man. He mumbled to himself. He was pacing up and down his house muttering angrily. Something was eluding this Malyalee that nobody understood.  (People from the state of Kerala, in South India are often called "Malyalees") The fact that he mumbled to himself was quite well known in that household. All the children in that traditional "naal-kettu" (house with a courtyard) sometimes giggled in the background at this eccentricity. But not loudly. For Madhava can suddenly stop his pacing and give that angry glare of his, another well-know trait, which can strike fear in any child. 

Every once in a while, people would see him suddenly dart into his room. Nobody knew what he really did there, because he was quite an intense, private person who  had resigned himself to the fact that nobody understood him. Only a few trusted and loyal students, knew what he did there. They were privy to his work: he would scribble some notes on "ola" (coconut leaf) which was the medium for writing in ancient Kerala. He was a mathematician and an astronomer; terms that the ancient people had not fully understood or defined.

Everything keeps moving in Kerala. Every leaf trembles. Each and every branch sways. In Kerala, there is always movement all around. It was Nature's way of teaching the concept of iteration (cyclic repetition and re-examination) to this mathematician, Madhava; who often used  such a device in his work. However, during sunsets, the effervescence due to these natural iterations dies down a little bit.

The quiet hush of a Kerala twilight comes in quickly in the evening. The dappled shadows of the gently swaying trees that shrouded the horizon soon morphs into darkness. It is almost akin to the sudden sunset in a valley: For the thick greenery which enveloped every horizon around any given space in Kerala was akin to being inside a valley; a valley of thick, ever-moving greenery.

Madhava paused his pacing as he saw the silhouetted giggling children prancing in the traditional Kerala house courtyard that evening.

A child came with a lamp. "Deepam, Deepam, Deepam"  ... she chanted as she carefully manoeuvred  into the courtyard, with one palm gently shielding the flickering flame on the lamp from the evening breeze.

That traditional chant  "lamp, lamp, lamp ... " echoed around the house. 

It was a warning to  the demons: Darkness will not conquer that household. The lamp will now serve the purpose of throwing light into that house making the dusk really beautiful.

The child kept the lamp right at the centre of the courtyard. Seeing this, all the cousins came rushing towards it; throwing long shadows all around the courtyard. There were many children in that large household. They were a joint family ... As if on cue, the children formed a circle around the lamp and bowed respectfully to the lamp, moving together in rhythm. They did this most evenings, as a ritual.

That evening, however, was different. 

The children's excitement could not be contained. For just a few days back the festival of Onam had just ended and they were all mesmerised by a dance they had seen the women-folk performing. Onam was the festival where the much beloved mythical Kerala king, Mahabali is said to visit every household in Kerala. Malyalees believed that Mahabali was so close to them that he wanted to ensure that they were doing well at least once a year. That was Onam. The legend of Mahabali is yet another story, which I will not get into as that would be a digression from this quaint little story that unfolded that evening.

The children had seen many ladies perform the traditional "kai kotti kalli" (Literal translation: a play involving clapping of hands) during the festival. And they had confabulated among themselves to perform that dance that evening. The dance started with the ladies gathering in a circle around a lamp, gracefully stepping back to form a circle; and dancing around the lamp in a curious rhythmic fashion.

That is what the children did. They started this dance. As there were no photographers around to capture that event that day, here is the video from YouTube which shows such a dance performed by ladies. The tradition continues even today by many women-folk of Kerala, especially during Onam.

Madhava stood transfixed as he witnessed the little children dancing. The children had learnt every step of the dance, and he saw them stepping a few steps in one direction (clockwise) around the lamp, and then turn back and step in the opposite direction (counter-clockwise) Every now and then they would clap their hands in rhythm to the song they were singing. The clapping gave a momentary pause in the dance so that every dancer could correct herself and catch up, in case there were errors. Every once in a while, they would step towards the centre of the circle, the lamp; and then step back once again to resume the iterations around the lamp.

If one could only capture the smile that slowly occupied Madhava's stern face... It would have captured that very moment when Madhava got enlightened. His smile was brighter than the lamp in the courtyard. He chuckled as he ran into his room to scribble some more notes into his "ola"

The original "ola" written by Madhava was lost in time. Luckily, some of the students had preserved the work in their own notes. Subsequently, many scholars pored over Madhava's work and they have been wonderstruck for quite sometime now. He was possibly the first mathematician who discovered a remarkably accurate method to calculate the value of Pi.  

In Madhava's text, they saw a series written down and they were mystified why one term was a negative -- going in one direction, and the other one was a positive one -- going in the other direction, and the entire series kept stepping rhythmically in that fashion into an infinite series. They were most mystified by the fact that once in a while, the series corrected itself; eventually rendering the value of Pi with amazing accuracy. 

Many centuries later; something called the Internet happened in this world and a website on the Internet gave the essence of these scholars' interpretation of Madhava's work. I now quote the appropriate section of Wikipedia verbatim below. 

It seems they are still not sure how Madhava managed to write the equation for Pi. Moreover, they still are not sure how Madhava got the correction terms. Maybe if they were present that evening at Madhava's household witnessing the little children dance in the courtyard, the Wikipedia entry would have been different.

Start of quote:

Madhava's work on the value of π is cited in the Mahajyānayana prakāra ("Methods for the great sines"). While some scholars such as Sarma feel that this book may have been composed by Madhava himself, it is more likely the work of a 16th century successor. This text attributes most of the expansions to Madhava, and gives the following infinite series expansion of π, now known as the Madhava-Leibniz series:

which he obtained from the power series expansion of the arc-tangent function. However, what is most impressive is that he also gave a correction term, R_n, for the error after computing the sum up to n terms. Madhava gave three forms of R_n which improved the approximation,namely

R_n = 1/(4n), or

R_n = n/ (4n² + 1), or

R_n = (n² + 1) / (4n³ + 5n).

where the third correction leads to highly accurate computations of π.

It is not clear how Madhava might have found these correction terms.The most convincing is that they come as the first three convergents of a continued fraction which can itself be derived from the standard Indian approximation to π namely 62832/20000 (for the original 5th c. computation, see Aryabhata).

He also gave a more rapidly converging series by transforming the original infinite series of π, obtaining the infinite series

By using the first 21 terms to compute an approximation of π, he obtains a value correct to 11 decimal places (3.14159265359). The value of 3.1415926535898, correct to 13 decimals, is sometimes attributed to Madhava, but may be due to one of his followers. These were the most accurate approximations of π given since the 5th century

The text Sadratnamala, usually considered as prior to Madhava, appears to give the astonishingly accurate value of π =3.14159265358979324 (correct to 17 decimal places). Based on this, R. Gupta has argued that this text may also have been composed by Madhava.

The "Why" of BIM

I believe one needs to ask some deep "why" questions which will lay down the objectives of open source BIM. I subscribe to the thought explained by Simon Sinek in a TED presentation: http://www.ted.com/talks/simon_sinek_how_great_leaders_inspire_action.html

A lot of useful innovations have happened because leaders asked and answered the question "Why" first before answering questions such as "How" and "What"(Simon Sinek explains not only in the context of business but also in social movements, such as Martin Luther King's points...)

So first of all, I recommend we really get into the question "Why".  This article is based on some discussions that is happening currently in a Google group in India, exploring open-source BIM.

Why do we need Building Information Modelers and why is it important to think of it once again ... not just take off from what is currently existing. (To be graceful to what is existing: We could do our exercise and later on realize that current standards are useful, but we need to carefully tick-off on each of the following points before doing that)

1. Because we need to support the entire spectrum from concept formation all the way to construction

Designing is a spectrum. It starts hazily from an architect's mind and proceeds towards final, crisp stage. Ideally, BIM should cover the entire spectrum. There has been some attempt from the West to computerize early stage designing. (e.g. SEED ) but those did not take off. Currently, it is taken as granted that BIM is done towards the final stage.

No doubt, there are companies that have tried to use BIM in earlier stages too ... and some commercial organizations confuse us further by claiming that things like massing, etc. can also be done using BIM for helping in the early stages. But the theories behind that approach need to be investigated. What we must realize is that information management is necessary at all stages of designing and all the way into construction. It is not just help in "visualizations of massing"

Earlier the information is handled; better it would be for design. Currently, it is assumed that all the messy, hazy stuff that happens during the initial design stage is best done by architects using their favorite methods ... and later it can be transferred to computers. One of the prime reasons why many architects ( especially experienced ones) do not take to computerization and BIM is because they see a disconnect between the early stage and the final stages of design. Currently the situation is: Early stage = NO computerization. Final stage = Computerization. Ideally, what I have been striving towards for last 20+ years is to look for computerization as a help, not just a thing to be used entirely, who can sit side-by-side with an architect and later on engineers and other consultants EVERY STEP OF THE WAY.

2. Because we need to record design intention, not just the design

Many think of architecture as the way it is finally seen out in the real world. That is just the tip of the ice-berg. But beneath the surface, there has been a lot of decisions that went to make the building what it is. What is also needed is to record all the intent, nebulous qualitative attributes, decisions that were forced due to management practices, etc. The reason this is important because architecture can be put to many unusual uses and situations. A building may get converted later on its lifetime. A warehouse can become a clubhouse. An award winning building may later on be found to have very serious problems later on and when the problems surfaced, there would be serious people wanting to investigate what went wrong so that the same causes do not surface in other buildings.

The most dramatic example of such a situation was what happened before the collapse of the World Trade Towers. The context was never experienced before, and so nobody could really predict how the buiding would perform in that crisis. Sadly, this was the SECOND project of the same architect which had seen dramatic failure. The first one, the Pruitt-Igoe housing complex, was equally dramatic but it was demolished not by terrorist attack  but by the state who found that the award winning project of that architect was almost completely useless. Finally it was dynamited. As per Charles Jencks, architecture historian, it marked the day when "modern architecture died". Pruitt-Igoe is a famous study that is spoken among architecture researchers but not much outside. http://en.wikipedia.org/wiki/Pruitt%E2%80%93Igoe

This issue can be seen in earthquake relief, emergency situations, fires, etc. Sometimes one may need to model movement of people through the building. There has been many cases where people move en-masse towards the wrong exit in case of a fire. Recording design intentions can be very useful in such a case, because one can assess what kind of management directives and steps should be supported and what should not be. For e.g. An irritating client could insist on closing a window opening (it has happened with me) and later on it was found that for the lack of that window, the apartment did not perform correctly climatalogically

3. Because we need to save time

Saving time happens on multiple levels. One is saving the mechanical drudgery of making drawings, models, printing etc. That gets saved when there is a single BIM model to refer to. But more subtle is the saving of time when the management of the design process is properly supported. To give an analogy: Calculators did save time for calculations, but when the financial planner got a spreadsheet, he did not get just some calculator with additional capabilities but it opened up a lot of "what-if" calculations that the planner could now do and then use those creatively. Much, much more time gets saved. The approach to BIM therefore should NOT be just "okay, we need to have a very good way to put all the geometric information together, holistically" Yes, that is one goal. That has been somewhat achieved by current BIM but that is not sufficient

4. Because we need to respect the end user as contributors to the model

As per Stephen Covey: "Problems are solved twice. Once in the mind and once in the real world" Modeling is NOT the whole sole property of people like me and others developing BIM, the people who make the proposal. But a model should ideally be open to receiving inputs, sometimes even at the last moment, from the actual user. This trend can be seen in many other data standards too. For example; when Tim Berners Lee proposed the HTML standard it was a "hand-me-down" set of data constructs that the end user had no choice but to use. But that approach is changing. Today, HTML 5, XML allow for new elements to be inserted by the user as he deemed fit, that follows meta-rules.

If you look at BIM standards carefully, you will notice that much of it is still archaic data-structure approaches of yesteryear. (I can give references and my insights in this later) I suspect, much of the current BIM standard has been manipulated so that the commercial organizations that helped create them could ensure that their own proprietary software continue to get traction

5. Because we should respect the D-R-Y principle

DRY = "Don't Repeat Yourself" is a well established concept in computing. Any form of redundancy that comes into data structures can wreak havoc. DRY was a term I think invented by the Ruby-on-rails people which essentially mean the same thing. However what is "repetition"?  There are obvious ones and unobvious ones. But opinions vary which is which. A piece of data which is repeated to me; to someone else it may look quite harmless and done just to get some specific job done and therefore can be accepted. For e.g. Using construction lines to draw other elements is a known practice among draftspersons.  Often the construction lines are left behind quite harmlessly. It may be okay when we speak about drawings but when it comes to modeling, if some object was created only for creating some other objects (say a CSG model) and then if that is left behind it can confuse others using the data.

In architecture models, there is one major issues that many BIM and CAD programs do not think is very critical: That is repetition of "spatial volumes" For  e.g. If I draw 4 walls that enclose a room to the visual eye, there is a space that is enclosed but then it is not measurable as the data-structure cannnot glean that out. So people are instructed to happily insert another volume that denotes the space -- and architects do that without knowing the implication --- that is very subtle redundancy there and that can lead to, and often does, very serious problems during automated objective analysis of the data. For e.g. If the data is to be queried for the area of the room inside, it may initially give the right figure ... but when, during some modifications, the walls are moved around (which also should imply that the object denoting the space of the room should also be modifed- -- but many time it may not get modified due to oversight) then we have a very serious problem because the room will still reveal the old area and not the new one after the walls were shifted

6. Because we should also respect all kinds of design processes and thinking

When designing, an architect often starts delineating the spaces in the early stage of design. Usually. But not always. For e.g. as an architect I often work in that way. But there are architects who may work on the built-forms earlier... or it could be a mix. Even with spaces, there is no really rigid rule which kind of space need to be represented first. I had adopted an unusual approach for a hill-resort I was designing in Munnar, Kerala in India. When I went to the site, I first located the various views that I wanted to capture -- so effectively, I was first working out the potential locations for the window openings rather than the rooms to which those openings would go. I had to have a modeling system that allowed me that -- lots of windows hanging around inside my early model; without knowing which rooms those windows would eventually belong to. Later on, when I figured out what are the rooms that resort needed, I arranged the rooms to take advantage of the previously located windows.'

Current BIM standards are extremely rigid on the way data is arranged. For e.g. In most BIM, I doubt whether one could create an opening without first creating the wall into which the opening is placed. That approach looks logical. People sometimes wonder, how can one construct an opening if there was no wall around it? That is right when construction is concerned; but when an architect wants to start thinking about a design he may want to first think of the openings and then the walls.

There is a much-bandied term called "ill-formed" objects in CAD and BIM (objects that geometrically could be constructed on the screen but cannot exist in the real world)  There have been data-structure approaches such as the "split-edge" data structure proposed by Yehuda Kalay and others from Berkeley which tries to put all the data in a non-redundant manner into the computer. But then I found it too rigid and not respecting the need for architects to sometimes think non-linearly, or out of sequence. That is why I find that current BIM is more construction oriented instead of design oriented

7. Because we need to incorporate concepts that have found to work in other areas such as management, computer programming etc

Today, the "agile" process of software development is very well known and respected. Many programs are designed using those principles. I believe that approach (i.e. the spiral-development approach using Agile) is very useful in designing and the data standards should help achieve that. In an agile process, the design is quickly developed, criticized, tested and then dismantled if so required, so that the next design cycle can be quickly started. What happens in traditional CAD and BIM is that the process starts gathering a lot of complicated stuff as the representation proceeds. An architect finds it extremely difficult to dismantle something that he has modeled just so that he can re-examine the holistic again in another agile cycle. Conventional CAD/BIM is not very respectful of the agile process

Another concept that I would love to see in BIM is "just-in-time-designing" which is derived from "just-in-time manufacturing". In JIT manufacturing, there is a lot of advantages because inventory costs can be very low, and errors removed fast. Some JIT processes are now seen in computing too (JIT compilers, for example) I strongly believe that just-in-time techniques should be available to architects too : Often the decisions that go towards making a really good design come and "click" into place at the very last moment (i.e. "just-in-time") The data standard should be respecting such a need. Again, this means the data should be very light and should NOT pick up too many heaviness as the design representation progresses