Many of us may have noticed that we reflexively choose our language to suit the person in front. This includes not just choosing language out of the set of languages we know, but also choosing the tone, vocabulary, complexity, accent, and so on. It may happen that we can speak a language with one person fluently, but have to put an effort on that language when talking to another person, even if the language happens to be our native one. Personally, for example, I find it difficult to speak in Marathi, my native language, in a group when even one of the people does not understand it well. Not that there is a lot of thought behind; my reflexes simply work in the other direction. We also simplify our language when talking to small children. Or when talking to people who have only one language common with us, and that too they don’t know well. I also happen to vary my accent and dialect of Marathi depending upon the person in front.

Today I discovered another fascinating aspect of this phenomenon. I was listening to a Marathi song by Rafi. I have almost never heard his Marathi songs, although I know there are a few. And in spite of being aware that this is a Marathi song, I simply couldn’t understand the words in the first shot. The voice of Rafi had this biasing effect on me (apart from the magic it has!), that I kept on falling back to expecting Hindi. I had to put efforts to ignore the voice or get beyond it in order to actually find out what the words are!

Our speaking and listening faculties seem to go out of the way to get tuned to the person in front of us… Languages are made to order.

When we needed computers,
and learnt our A-B-C,
it was always dear Fortran,
and Fortran it will be.

Our variables are X, XX,
Y and then YY,
except when they’re integers,
then they’re I, II

However large our programs get
a thousand lines or two,
here we jump, and there we go,
with our old GO TO.

Some of us write subroutines
we call them insane,
The rest of us are happy with
one big PROGRAM MAIN

Some folks try to brainwash us
for using language C,
but all that nasty pointers stuff
makes us feel dizzy.

Then we hear a step further,
a thing called C++,
classes, objects, and what not,
why such a complex fuss?

A dozen or so more fancy names,
although we have seen,
whatever those are really for,
we’re not really keen.

We are shocked to see so many,
hundreds and hundreds in breed,
when we have our old Fortran,
what else do we need?

So many are gone with time,
and so many will be,
it was always dear Fortran,
and Fortran it will be!

That must be a grad student
scribbling a longish scroll

And this must be a postdoc
he is not writing at all

The young prof with his energies
is trying arguments deep

And that’s an old prof with a halo
in the front row, asleep

When you reach the point of pride
a cellphone goes beep-beep

Of course it is the director
with another meeting to keep

The show goes on, and you talk of results
but you can’t show them the sweat

And then come tea and biscuits and snacks,
the best of a seminar, you bet!

All the C courses and books that I have seen, introduce arrays early and pointers later, sometimes much later. Pointers have the reputation of being difficult, and this postponing makes it worse. Further, the C language ties up the concepts and pointers and arrays in an essential manner, but it does not get imprinted onto the students’ mind because of this delay. To emphasize this tie-up and to give students a longer exposure of pointers, I decided to introduce pointers right in the beginning, just before arrays which come quite early. Here is a summary of the new flow of concepts, which takes about two to three classroom hours:

Like the other types such as double, int, char, etc. which store different types of information, we have one more type: the pointer type. The variables of this type can store addresses of memory locations. Otherwise, these variables are just like other variables: they can be assigned values of appropriate types, they can be passed to functions or returned by functions, they can take part in their own arithmetic (which is different from the integer arithmetic or the floating point arithmetic, and will be covered later), etc. The pointer type is further qualified by the type of data it can point to: For example, a pointer of type int * is taken to contain address of an integer. In addition, there is a generic type of pointer, void *, which is pointer to no specific type (so it can be used to point to anything in general).

There are ways to create values of this type: the address-of (&) operator is one common way. The expression &x has a value that represents the address of a variable x, and can be assigned to a pointer variable of the corresponding type. There are ways to use address-values: a common way is the dereferencing (*) operator. If p is a pointer of type int *, then the expression *p represents the integer that is located at the address that p contains.

And now come the arrays: An array, say of 10 integers, is declared as

int k[10];

This declaration makes k an array of 10 ints, only by

• reserving a contiguous space of 10 elements
• making k a constant whose value is the address of the first element

Then comes the turn for pointer arithmetic, for accessing the elements: When we know we have 10 elements placed contiguously and we have k as the address of the first, k+i represents the address of the ith element (counting from zero). Thus i acts as the offset. The expression k+i means the address of ith element irrespective of the type and the size of the array elements by the definition of the language. Since k+i is the address of ith element, the actual element is obtained by dereferencing it: *(k+i). Now since arrays are so common, the C standard has provided another convenient notation, k[i], which is exactly equivalent to *(k+i). And this is true even when you have a pointer variable in place of k. Pointer arithmetic makes it clear why arrays in C have 0 as the index for the first element. Further, this is a good time when passing of arrays as arguments to functions can be easily understood simply as passing of pointers.

I am curious to know whether such an approach has been tried anywhere else, and their viewpoints.

Part 2 of this series suggested ways to start practicing thinking like a programmer. However there is much more to it. Modification and growth is inevitable for most of the programs. If no appropriate thought is given to these possibilities during the development of a program, then there are limitations to the speed of its growth and modifications: The program organization soon goes out of control. For example, one change in desired outcome may require several changes at several places in the program, and not all of them will be obvious at once. It may turn out to be a lot of trial-and-error cycles of effort to find all such places. The advanced techniques of program organization have such concerns as their central theme.

One of the focal points of these techniques can be called separation on concerns: The task that the program is going to perform has some logical division of concepts. Separation of concerns is achieved by physically separating subtasks related to each logically separate concept into different units. This way, whenever a change is needed, it can be quickly figured out what “concepts” in the program need to be modified, and plan the modification accordingly. This significantly reduces the scatter of modifications required to achieve a single change in outcome of the program.

Another focal point is abstraction and generalization: If there are more than one similar but slightly different subtasks that the program needs to perform, is there a way that they can be performed by a single unit (say a function or a set of functions) inside the program, under slightly different inputs? The motivation: if we understand a group of tasks as similar, then by writing a single unit to handle them, we are reducing the source of errors to that unit. So when a modification is required, or somebody needs to understand that group of subtasks, the number of changes or readings that are required are restricted to that particular unit, not a few almost identical copies of it. Abstraction and generalization also makes parts of the program reusable in future programs.

These can also be described as efforts to increase the human readability of a program. If a program needs to be modified, usually by somebody else, or even ourselves may be six months after writing it, then it must first be understood. It stands a fair chance of being understood when it is written to be read by humans.

Although there is a lot of terminology and buzzwords around, the progression of techniques through structured programming, modular programming, and object oriented programming on the one hand, and functional programming (my favorite) on the other, are essentially in such directions as above. Further, they are not replacements of a good understanding of behaviour of programs; they only help us in creating big programs provided we understand small ones well.

We are taught in schools that light travels in straight lines through air or vacuum, and we also have “experiments” to “prove” this. One of them that was in my books was to arrange three cards with a small hole in each them so that the holes align in a line. Then we put a candle on one side so that its flame is also aligned with the holes, and then look at it from the other side. To our delight, we see the flame. Now move the middle card so that the holes are no more aligned, and what a surprise, we don’t see the flame through the holes any more!

There are other “proofs” and “experiments”, some of which you can get with a google search on a string such as light travels in straight line. As of now, this is what a few top results talk about in our simple context (i. e. apart from those talking about changing refractive index or talking about General Theory of Relativity): A few of them replace our rudimentary candle with a flashlight. A few others use a pinhole camera as an example and draw lines from the object to the camera screen. Then there are arguments based on sharpness and position of shadows. Yet others show the magnificent photographs of the shadow lines that are formed by clouds on the other side of the Sun when they block the sunlight.

All of them, however, take it for granted that the concept of a straight line is well-defined, a priori, independently. In pure (Euclidean) geometry it may be, but we need to examine how do we determine whether some physical shape is a straight line. Again let us go back to the three cards experiment. How do we check whether the card holes are aligned in a straight line?

If we decide that by looking through the holes to make sure we can see through, then clearly our reasoning is circular! All that we can conclude when we place the candle on the other side and are able to see the flame, is that light follows the path that light follows. So let us try to be sophisticated and see if we can confirm the collinear alignment without looking through the holes. One way is to make the three cards of exactly the same size and make a hole in them in exactly the same position. Then we can align the cards and the holes will be aligned with them. But how do we align the cards? If we check their alignment by trying to see if their corresponding corners and edges visually coincide from a particular position of the eye, then we are doing the same thing in essence: trying to align them in a path that light follows, which is again circular. What if we push them all together by a straight ruler so that they are aligned with the ruler? Sounds good, except that how do we know that the ruler’s edge is a straight line? By looking at it from the side so that all the edge of the ruler seems like a point? Circular again.

In short, one of our main methods to check whether something is straight, involves trying to put our eye in the line and see if it is all one behind the other. One of our practical definitions of a straight line in the physical world is the path followed by light. It is almost our natural instinct, so much, that we even use it while talking about path of light itself! Obviously in this case we are being circular in our reasoning.

If we want to really verify that light travels in a straight line, we must base our method of verifying the straight line on some other definition. One such definition that I can think of, in the context of Euclidean geometry, is that of the shortest path between two points. How do we physically find out the shortest path? One way is to take a very light, thin, unstretchable but otherwise flexible string, and hold it at the two given points so that it is fully stretched. Now we can convince ourselves that the string indeed occupies the shortest path between the two points. (If it did not, then we could stretch it further until it did.) Now if light follows this path, then it can be indeed said that light has followed a straight line, a straight line confirmed by other means than light itself.

So if we insist on the candle-behind-cards experiment again, the holes can be aligned by passing this string through them and stretching it so that the cards move and holes align, fixing the cards, and then removing the string. Now if we see the flame through the holes, or even if we could just see through the holes, we are done. But why do we require the cards and the candle? Just stretch the string, put our eye in the line of the string on one end, and indeed we will see that all the string looks like a point. So the path of light is along the string, which is a straight line.

Of course I am not considering change in medium (varying refractive index), or effects of gravity (via General Theory of Relativity). But it is interesting to see that even in a very elementary setting such as the ordinary three-dimensional Euclidean geometry, and only air or vacuum as the medium for light, we can commit blunders of reasoning.

I am interested to know any other independent definitions of a straight line that can be physically used in this context. Please do comment if you have any.

Part 1 of this series made the point that getting a problem solved by a computer requires developing a precise, detailed, and fixed plan of action in the form of a program, which is a drastically different form of thinking as compared to how we solve problems as human beings.

We need practice in order to learn this form of thinking. We need to challenge ourselves into programming more and more complex problems. Further, to make this practice effective, we need to follow a few principles while solving a programming problem:

Firstly, to get a fair idea of many details of what the program should be doing, we should be able to manually solve the given problem (usually on paper):

• In a way conceptually close to the one we plan to eventually program,
• In a variety of cases of inputs,
• Repeatedly and systematically.
  

Although we should use the method that we plan to use in our program, otherwise the focus here should be to solve the problem ourselves, without bothering about the programming details, since the purpose is to get a picture of how the solution proceeds. Further, this exercise is useful even if the algorithm that we are going to use is well known, because what this process gives us is experience, which is much more valuable than just the in-text knowledge. Another aspect that this exercise clarifies is what exactly we are trying to produce: a clear picture of the desired outcome. Without it, programming efforts lack a clear direction.

The next principle, and the most important one, is to observe and note down the systematics. We may make some observations during the first phase, but unless we focus on it, we will not get it all out. Again, this is rarely done apart from programming, so it needs conscious attention. Break all the reasoning down to pieces, till you get a feel that each of them is mechanically doable and there is no “mind” or “intuition” required to do it: try to trace the jumps in intuition. The same thing applies for combining these pieces: it should also be possible in a mindless way. This is how the organization of the program emerges.

After this comes the relatively easy part: to translate all the pieces and ways of combining the pieces into what is available in the programming language we are using. Note that it is easy only when we have isolated thinking about the program organization from it.

It is still not possible, after all this exercise, to guarantee that we have covered all the cases, or our program is perfect. This is natural because of our way of problem solving: we adapt rather than fully plan. This is true not just for novice programmers, but all of them. That is why debugging and improving are part of the central activities in the software world. Once we get comfortable with the fact that no program is perfect, we gain confidence that we will still produce something useful, in spite of the fact that it will constantly need corrections and improvisations.

Here is the principle behind the principles: as mentioned in part 1 we tend not to think about all the details right away. Such a requirement of details sometimes makes programming overwhelming for novices. The process of manually solving the problem and analyzing how we solved it take us through many details which will help us build the program. Further by making the steps conscious and separate, we avoid the overwhelm of facing it all at once when we directly start programming.

Further, with practice, the complexity of the pieces of a program that can be handled right in the head increases. But for most of the problems, some kind of clarification remains necessary, and is a significant part of the work, before we jump into the popular image of a geek focused hard onto the screen and typing like mad into the keyboard.

Part 3 of this series takes a view of a few established techniques for managing the complexity of larger programs.

A key component of programming expertise is to be able to imagine how a computer would solve the given problem. In other words, it is the ability to exactly specify a procedure that should be blindly followed by an agent (the computer) to get a solution. The procedure has to be in terms of certain basic operations and a few ways to combine them which are the only things the agent “understands”, or rather, can execute. It turns out to be one of the harder crafts to learn for novice programmers, compared to learning the syntax, or learning about the basic operations and the ways to combine them.

I think the reason for this difficulty is very fundamental. The thinking patterns required when we solve a problem ourselves, are drastically different from those required when we want to program a computer to solve it.

The human approach to problem solving, be it the prehistoric hunting, or a modern mathematical problem, is to act dynamically according to the current state of affairs in order to progress towards a solution. We do have a plan, whether it is formally written down, or in our minds, based on our knowledge and previous experience. But the purpose of the plan is to serve only as an overall direction for our actions. We judge from time to time whether our current course of actions is taking us closer to the outcome picture that we have in mind, and evaluate the plan itself in the process. The plan is nowhere close to a detailed step-by-step instruction sequence to be followed exactly. (In fact there are situations where such plans are required. Following a such detailed step-by-step plan requires discipline and training.)

Further, we do not, and need not, anticipate all the situations that will upset our progress. Our plans do have a certain amount of contingency considerations, but in many situations we revise and adapt the plans.

We have evolved to be solution creators, since the environment in which we are supposed to survive is extremely complex, and any detailed plan will eventually go for a toss. We create new solutions or find new ways if the unpredictable environment upsets our original plans (and it will). We are comfortable with vague plans, and confident that the details will appear in due time. In short, our way of problem-solving makes the road appear as we walk, rather than choosing a path from an already existing road network.

On the other hand, when we program, we are developing a precise, detailed, and fixed plan of action, i. e. we are solving the problem in an apparently unnatural way. We have the responsibility to imagine and plan for all sorts of situations that the world (within the computer) could be in, with clarity. We are no more in our natural comfort zone of only deciding the overall direction in the beginning and let the course of actions adaptively fill in more details. To novice programmers, this required clarity at all steps and levels at once is new and could be overwhelming.

Overcoming this barrier requires practice, like any other skill. Part 2 of this series will present some thoughts in this direction.

When we design a course from scratch, we have the whole picture. We identify ourselves with the design, and the course thrives on this identification. On the other hand, when we use a syllabus that is already laid out for us, or even when we reuse our own design next time, it may set us in driven mode rather than driver mode, of following a given path without much control. We may notice several glitches and bumps as we teach or prepare to teach, like:

• Major flaws in the design
• Topics that we wanted to do better than the last time
• Topics for which we wanted to try different approaches
• Required adjustments to relative emphasis of various topics
• Need to change or introduce new exercises
• Need to incorporate new things in the field
• Need to incorporate our improved or alternative insights
• Obsolete things (especially in technology) to be reduced or removed
• Need to realign the course in the larger view of the entire programme that the course is a part of

But it may be too late to do anything about these when we notice them, since we also need to prepare for the actual lectures. Thus we may start loosing our identification with the design.

A few reviews, done consistently, can help us keep the design up to date, and maintain our identification with the design: First review is that of the entire plan, well before the course begins. And then we need periodic reviews while the course goes on, such as biweekly or monthly, of the remaining plan of the design. These reviews help us notice such things in time, and gives us chances to incorporate such things in a timely fashion. We can reestablish our identification with the design, keeping life the course.

Such a review may however be overwhelming, because we may notice a lot of stuff that needs to be done. A step by step approach can help us here:

• Keep the review just a review. Make no changes at the review time. Just note down whatever occurs to you while going through the design.
• Later on separate the notes into distinct, possibly related, desired outcomes.
• Work on each of them one by one.

When we know we are teaching according to our best plan, teaching is an amazing experience!

This is the third time I am introducing the C language via our “Programming For Modelers” course at CMS. The course is not just about learning a language, but learning to think about and develop programs. My way of teaching has always been developing programs right in the class, using a projector for the screen, and talking about the thought process and required information as I program. The motivation is to let the students see how thoughts and programs evolve, and how solutions are arrived at. However, it always carries a risk: I can make mistakes, and cause serious bugs in the programs. In spite of this, students being exposed to seeing programs being developed in front of their eyes is a great idea.

For sure, I did make a few mistakes along the course. My approach till the last year was to use all my might to get that bug out as soon as possible, so as to continue with the flow of the lecture as planned. And that meant thinking very fast and silently, leaving the students clueless for may be two to five minutes.

Thus mistakes and bugs were only diversions away from my lecture plan, to be got rid of as quickly as possible. I sincerely hoped before every lecture that I would write correct programs in the class right away.

This year I realized not only that such mistakes are unavoidable, but also that I need not treat mistakes as something just to be gotten rid of. After all, programming is as much about debugging as it is about designing. So I decided to use mistakes to an advantage: I would use them as opportunities for demonstrating the debugging process.

So now I make my debugging thought process explicit and conscious. If I find my intuition running way ahead of my explanation, I try to trace it and lay out all the thinking steps in front of the students. I try to demonstrate how one can pinpoint the problem. I try to take babysteps which are unnecessary for myself, but which I think would be useful for the students in order to get used to the process.

I have no quantitative ways to find out how much better this is, but I am satisfied with the result so far. In a sense, now I actually look forward to making mistakes in the class!

A common misconception that is exactly 22/7: origin and remedy

Many of you may have noticed that a large fraction of students are under the impression that the value of is 22/7. Exact. These students have no idea that the rational number 22/7 is just an approximation to the irrational number .

I think the reason lies in the way schools treat : There might be a couple of mentions that 22/7 is an approximation, but it remains under-emphasized. On the other hand, see the “numerical problems”. Notice the multiples of 7 in diameters or radii in almost all the problems, hinting the students to use 22/7 as and get non-fractional answers! With such practice problems for many years, 22/7 is firmly imprinted on students’ minds as the value of .

I think we can do better: Make the students use various approximations. Let them choose their approximation options from many possibilities: 22/7, 355/113, 3.14…, and so on. Also make them aware of the fraction of error with each approximation; possibly ask them to calculate that. When talking about the value of or results of calculations using , make them always say “approximately”. (We have such rituals in other places: for example we make them write an additive constant C when they calculate indefinite integrals! We even cut points for missing that!)

The point is that it is not a problem if students do not know the exact value of , because nobody does! But they should know that the values that they use are approximations.

During a recent discussion with Prof. Gangal, my PhD advisor, I noticed an irony of mathematical “counter-examples”: On the one hand, there are usually many more pathological cases than regular cases, but on the other hand they are difficult to construct.

Take rational numbers versus irrational ones for example. Rational ones are easy to imagine. Irrational ones need more explanation. But on the other hand, rational numbers are countable, whereas irrational numbers are uncountable. Even within the irrational numbers, there are simple ones like the square root of two, and then there are not so simple ones. Again the simpler ones are rarer than the rest.

Another example is that of smooth functions versus non-smooth ones. In some sense of cardinality, smooth functions are rare in the space of all possible functions, but they are the ones that are the easiest to imagine or construct.

My advisor looked at it from the other end: What we can easily imagine or construct is what we call regular, and we study them more extensively. We call others as pathological.

Illustrates that the human knowledge is finite, while the unknown is infinite!

Today I came across a website which lets you check your typing speed. I am a touch-typist (one who can type without looking at the keyboard) for a long time, and in the five or so tests I took, my speed ranged from 75 to 90 words per minute (78 words per minute, for example, is 432 characters per minute according to them).

The test gives you random sequences of frequently used English words in a line, and an input box to type those. After you type the last but one word, another line appears with the last word of the previous word which you are yet typing, so there is some kind of continuity in the text that you get.

What I noticed while I was typing was something interesting: I was not looking at the word that I was typing. I was always looking one word ahead. And my speed actually reduced when I could not look ahead well in advance, for example after the last word of the current sequence appearing on the screen, when I had to reposition my eyes to look for further words, or when I had to look back at the current word to confirm its spelling.

So my naive way of understanding this is that during touch-typing, while our motor control is working the fingers on a word, our visual and language interpreter is simultaneously processing the next word!

In fact my feeling is that when the words actually form meaningful sentences, our look-ahead is chunks of upto around four words, since we can easily grab and remember such meaningful chunks in one shot. It might actually improve the speed, since the fingers are also programmed somehow to type such chunks in one reflex.