## Turtles and More

My wife recently became interested in the Spirograph (™) system. Since her birthday was coming up, so did I, for obvious reasons. If you have never come across Spirograph (™) I can highly recommend it, as it enables the production of glorious swirls and spirals, using a system of toothed wheels and other shapes. When you use multicoloured pen, the results can be amazing.

Of course, I had to translate this interest into the computer sphere, and I immediately recalled “Turtle Graphics” which I have used before. It is possible to create graphics very similar to the Spirograph (™) designs very simply with Turtle Graphics.

Turtle Graphics have a long history, stretching back at least to the educational programming language Logo. Although variations of the original Logo language exist, they are fairly rare, but the concept of Turtle Graphics, where a cursor (sometimes shown as the image of a cartoon turtle) draws a line on a page, still exists. The turtle can be directed to move in a particular way, based on instructions by the programmer.

For instance the turtle can be instructed to move forward a certain distance, turn right through 90°, and repeat this process three times. The result is a small square. Or the turtle could be instructed to move forward and turn only 60°, repeating this 5 times to draw a hexagon. Using simple instructions like this allow the drawing of practically anything.

I use an implementation of Turtle Graphics in the turtle module of the Python programming language but it is probably available for other programming languages. Python is probably an easy language to learn from scratch than Logo, and in addition Python can be used for many other things than Turtle Graphics. Python is available for Windows, OS/X, and Linux/Unix, and for several other older or less well known platforms.

Where things become interesting is when the looping abilities of Python are used to enhance a program. If the programmer gets the turtle to draw a square, then makes the turtle turn a little and repeats the process, the result is a circular pattern. Starting with a more interesting shape can produce some interesting patterns.

After a while, though, the patterns begin to seem very similar to one another. One way to add a bit of variation is to use the ability to make the turtle move to a specific position, drawing a line on the way. As an example, consider a stick hinged to another stick, much like a nunchaku. If one stick rotates as a constant speed and the second stick rotates at some multiple of that, then the end of the second stick traces out a complex curve.

In Python this can be expressed like this:

x = int(a * math.sin(math.radians(c * i)) + b * math.sin(math.radians(d * i)))
y = int(a * math.cos(math.radians(c * i)) + b * math.cos(math.radians(d * i)))

where c and d are the rates of rotation of the two sticks and and b are the lengths of the stick. i is a counter that causes the two sticks to rotate. If the turtle is moved to the position x, y, a line is drawn from the previous position, and a curve is drawn.

The fun part is varying the various parameters, a, b, c, d, to see what effect that has. The type of curve that is created here is an epicycloid. For larger values of c and d the curves resemble the familiar shapes generated by Spirograph (™).

The equations above use the same constants in each equation. If the constant are different, some very interesting shapes appear, but I’m not going to go into that here. Suffice it to say, I got distracted from writing this post by playing around with those constants!

The above equations do tend to produce curves with radial symmetry, but there is another method that can be used to produce other curves, this time with rotational symmetry. For instance, a curve can be generated by moving to new point depending on the latest move. This process is then iterative.

For instance, the next position could be determined by turning through an angle and move forward a little more than the last time. Something like this snippet of code would do that:

for i in range(1, 200):
t.forward(a)
t.pendown()

t.left(c)
a = a + 1
c = c + 10

This brings up a point of interest. If you run code like this, ensure that you don’t stop it too soon. This code causes the turtle to spin and draw in a small area for a while, and then fly off. However it quickly starts to spin again in a relatively small area before once more shooting off again. Evidently it repeats this process as it continues to move off in a particular direction.

Another use of turtle graphics is to draw graphs of functions, much like we learnt to do in school with pencil and squared paper. One such function is the cycloid function:

x = r(t – sine(t))

y = r(1 – cosine))

This function describes the motion of a wheel rolling along a level surface and can easily be translated into Python. More generally it is the equation of a radius of a circle rolling along a straight line. If a different point is picked, such a point on a radius inside the circle or a point outside the circle on the radius extended, a family of curves can be generated.

Finally, a really technical example. An equation like the following is called a dynamic equation. Each new ‘x’ is generated from the equation using the previous ‘x’. If this process is repeated many times, then depending on the value of ‘r’, the new value of ‘x’ may become ever closer to the previous value of ‘x’.

x(n+1) = rx(n)(1 – x(n))

If the value of ‘r’ is bigger than a certain value and less than another value, then ‘x’ flip-flops between two values. If the value of ‘r’ is bigger than the other value, and smaller than yet another value then ‘x’ rotates between 4 values. This doubling happens again and again in a “period doubling cascade“.

I’ve written a turtle program to demonstrate this. First a value for ‘r’ is chosen, then the equation is repeated applied 1,000 times, and the next 100 results are plotted, x against r. In the end result, the period doubling can easily be seen, although after a few doubling, the results become messy (which may be related to the accuracy and validity of my equations, and the various conversion between float and integer types).

## In the Zone

(Ugh! I forgot to post this last week. My apologies)

Programming, as I’ve probably said before is a strange occupation. You start with a blank sheet, steal bits and pieces from where ever you can find them and glue them together modify them, add some bits of original (to you) code and try to think of all the possible ways your program can go wrong.

Then you try and break your code (and usually succeed at first). Programming is still very much an art form. Of course things have changed a lot over the years, and we are able to use the work of others to help us in our endeavours, but my first paragraph is still true.

In the beginning there was “Hello World”. This is probably the simplest program that does something visible. It doesn’t take any information in and its output, the words “Hello” and “World” are not very useful in themselves. Actually, I’d say that there is an even simpler program that takes no input, produces no output, and in the process changes nothing. A “null” program if you like.

A programmer writing a new program may well jump in and start coding by grabbing some other code that he or she has access to, but that stolen code was developed, ultimately, from “Hello World” or the null program.

A good programmer is one who steals code from elsewhere and modifies it to do what he or she wants. There is no stigma of plagiarism attached to this process, and it is in fact strongly encouraged that programmers share code. A spoof news item that I came across stated that all programming courses would be replaced with a course on how to find code on “Stack Overflow“.  I’ve been unable to find the link again, but I believe that the item was on “The Onion“, a well known satirical website.

Of course, such a  process may propagate errors or bugs across many programs, but it is such an effective strategy that it is used more often than not. If code exists to solve a problem then it would be silly to pass it by and write it ones self, maybe introducing bugs to the code. The advantage of “borrowing” code is that while errors and bugs may be in the borrowed code, many eyes will have looked at the code and there is nothing more that programmers like than pointing out bugs in the code of other programmers.

Stack Overflow allows anyone to post code and comment (up to a point), so code posted may not be top quality, but other programmers are quick to jump if they see bugs or inefficiencies in code. Contributors will also point out code which doesn’t follow standards or conventions in the programming language being used. This is considered useful, as the code, if modified, can be accessed and understood more easily, and may often be safer and free of more bugs than unconventional code.

 Embed from Getty Imageswindow.gie=window.gie||function(c){(gie.q=gie.q||[]).push(c)};gie(function(){gie.widgets.load({id:'kKBXH_YLQStrbchPXpgCeA',sig:'F4UT2n6jHkYKyOko5gBt0UF_Adj4wV7x3CZFuGfNfjM=',w:'414px',h:'414px',items:'527951137',caption: false ,tld:'com',is360: false })}); 

When a program is written it starts out as literally a few lines of code or even an empty file. Any programmer knows that a program grows swiftly and in ways that can’t be foreseen until it may be of enormous size. It won’t be all written in one sitting but is usually written in stages. I personally like to write my programs in very small chunks, building on what has gone before. I think that many programmers use this process, though there may be others who write a sizeable chunk of code before testing it.

Ah, testing! Testing is the less enthralling parts of writing programs. Any program must be tested, to ensure that it does all that is required and nothing else. Generally the program being written doesn’t do all that is required and does things that shouldn’t happen, and initially it is likely to crash or produce cryptic error messages under some conditions.

 Embed from Getty Imageswindow.gie=window.gie||function(c){(gie.q=gie.q||[]).push(c)};gie(function(){gie.widgets.load({id:'z5J4TdT9Tp9CJcu8tWbn0A',sig:'9WYiOWLP0ZZnrX7AU2bHyfFqjDHZsD62y7IqKTykiVU=',w:'407px',h:'421px',items:'482178627',caption: false ,tld:'com',is360: false })}); 

Testing is supposed to reduce the number of such unwanted happenings, and the programmer may do some rudimentary testing and may handle at least some errors. However the programmer will realise that users who are unfamiliar with how the program is written may well do something that he has not expected.

So clever people have developed ways of automatically testing programs. To do this they have had to write the programs that are used to test programs. And of course those testing programs may have bugs. You can see where that leads to!

When a programmer knows a programming language really well, he is able to literally think in that language. The word “literally” has been devalued in recent time, but I am using it in the true sense of the word. This is hard for some people to understand as they think of language as something like French or Tagalog, and they can’t understand how one can think in a programming language, which is qualitatively different from a spoken language.

An interesting thing happens when a true programmer is programming something. His thought processes become so involved in the process of programming and in thinking in the programming language that he loses track of the outside world. That’s why programmers are whimsically thought to subsist on fizzy energy drinks and dialled in pizza. It is because those things are easily acquired and the programmer can keep programming.

 Embed from Getty Imageswindow.gie=window.gie||function(c){(gie.q=gie.q||[]).push(c)};gie(function(){gie.widgets.load({id:'_h0aZnR_Q5NWdjZGNVooCQ',sig:'kgx8_YV4rnMMolsaHpliLZASE42cq0xZtqsSkPqZsXY=',w:'508px',h:'338px',items:'CB6973-001',caption: false ,tld:'com',is360: false })}); 

A programmer “in the zone” is so embedded in the world of the program that he or she may often be reluctant to leave that world and respond to irritations like bodily needs and colleagues. I doubt that there is a real programmer who has not surfaced from a deep dive into the depths of a programming problem and realised that all his colleagues have left and it is late at night or very early in the morning. That’s the reason programmers stay after all other people have left – they know that they can slay the current bug with just a few more changes and a few more runs of the program.

The zone has similarities to the state of meditation. While meditation is passive though, programming is an active state. In both cases the person basically disconnects from the world, so far as he or she can, and the concentration is directed internally. Now that I think about it, any deep thought, be it meditation, programming, or philosophising, even playing a sport at a very high level, needs such concentration that much of the world is disregarded and the exponent enters the zone.

 Embed from Getty Imageswindow.gie=window.gie||function(c){(gie.q=gie.q||[]).push(c)};gie(function(){gie.widgets.load({id:'-jdT1J5XSTBR5mVq28idLQ',sig:'2gaKmEI1nBFvOOXyD83GRCzPoPXL05emNtHhX_rMZJc=',w:'521px',h:'329px',items:'76185387',caption: false ,tld:'com',is360: false })}); 

## Documentation

Documentation. The “D word” to programmers. In an ideal world programs would document themselves, but this is not an ideal world, though some programmers have attempted to write programs to automatically document program for them. I wonder what the documentation is like for such programs?

To be sure if you write a program for yourself and expect that no one else will ever look at it, then documentation, if any, is up to you. I find myself leaving little notes in my code to remind my future self why I coded something in a particular way.

Such informal documentation can be amusing and maybe frustrating at times. When reading someone else’s informal documentation such as “I’m not sure how this works” or “I don’t remember why I did this but it is necessary”. More frequently there will be comments like “Finish this bit later” or the even more cryptic “Fix this bit later”. Why? What is wrong with it? Who knows?

The problem with such informal in code documentation is that you have to think what the person reading the code will want to know at this stage. Add to this the fact that when adding the comments the programmer is probably focussing on what he/she will be coding next, the comments are likely to be terse.

Add to this the fact that code may be changed but the comments often are note. The comment says “increment month number” while the code actually decrements it. Duh! A variable called “end_of_month” is inexplicably used as an index to an array or something.

Anyone who has ever done any programming to a level deeper than the usual beginner’s “Hello World!” program will know that each and every programmer has tricks which they use when coding, and that such tricks get passed from programmer to programmer with the result that a newcomer looking at code may be bamboozled by it. The comments in the code won’t help much.

 Embed from Getty Imageswindow.gie=window.gie||function(c){(gie.q=gie.q||[]).push(c)};gie(function(){gie.widgets.load({id:'R8hhrgf6QGdBn-Ja8cQ4vQ',sig:'hAZmayhCgMrm0JHOc9x42kDtnNuOeNMuglJUcyw68tY=',w:'478px',h:'359px',items:'182181688',caption: false ,tld:'com',is360: false })}); 

Of course such programming tricks may be specific to the programming language used. While the same task may be achieved by similar means at a high level, the lower level of code will be significantly different. While that may seem to impose another barrier to understanding, I’ve found that it is usually reasonably easy to work out what is going on in a program, even if you don’t “speak” that particular language, and the comments may even help!

While internal documentation is hit and miss, external documentation is often even more problematic. If the programmer is forced to write documents about his programs, you will probably find that the external documentation is incomplete, inaccurate or so terse it is of little help in understanding the program.

In my experience each programmer will document his/her programs differently. Programmers like to program so will spend the least possible amount of time on documentation. He/she will only include what he/she thinks is important, and of course, the programmer is employed to program, so he/she might get dragged away to write some code and conveniently forgets to return to the documentation.

If the programmer is at all interested in the documentation, and some are, he/she will no doubt organise it as he/she thinks fit. Using a template or model might help in this respect, but the programmer may add too much detail to the documentation – a flowchart may spread to several pages or more, and such flowcharts be confusing and the source of much frustrated page turning.

Of course there are standards for documentation, but perhaps the best documentation of a program would be to specify the inputs and specify the outputs and then a description of how the one becomes the other at a high level. As I mentioned above a programmer will probably give too much detail of how inputs become outputs.

Documentation tends to “decay” over time, as changes are made to the program and rarely is the documentation revisited, so the users of the program may need to fill in the gaps – “Oh yes, the documentation says that need to provide the data in that format, but in fact that was changed two years ago, and we now need the data in this format”.

The problem is worse if the programmer has moved on and gone to work elsewhere. Programmers tend to focus on the job in hand, to write the program to do the job required and then move on to the next programming task, so such code comments as there are will be written at the time that the programmer is writing them. Such comments are likely notes to the programmer him/herself about the issues at the time that the program is being written.

 Embed from Getty Imageswindow.gie=window.gie||function(c){(gie.q=gie.q||[]).push(c)};gie(function(){gie.widgets.load({id:'SHkPp9oBT-JbDvrr2uCyAg',sig:'Phx8M-eXHBtdJ0svwmFOGlDsffFHFfhxC0JhDiR9OPE=',w:'594px',h:'407px',items:'453714667',caption: false ,tld:'com',is360: false })}); 

So you get comments like “Create the app object” when the programmer wants a way to collect the relevant information about the data he/she is processing. Very often that is all that one gets from the programmer! No indication about why the object is needed or what it comprises. The programmer knows, but he/she doesn’t feel the need to share the information, because he/she doesn’t think about the next person to pick up the code.

I don’t want to give the impression that I think that documentation is a bad thing. I’m just pondering the topic and giving a few ideas on why documentation, as a rule, sucks. As you can imagine, this was sparked by some bad/missing documentation that I was looking for.

Open source software is particularly bad at this as the programmer has an urge to get his program out there and no equal urge to document it. After all, a user can look at the code, can’t he/she? Of he/she could look at the code, but it is tricky to do so for large programs which will probably be split into dozens of smaller ones, and the user has to be at least a passable programmer him/herself to make sense of it. Few users are.

So I go looking for documentation for version 3.2 of something and find only incomplete documentation for version 2.7 of it.  I also know that big changes occurred in the move from the second version of the program to the third undocumented version. Ah well, there’s always the forums. Hopefully there will be others who have gone through the pain of migration from the second version to the third version and who can fill in the gaps in documentation too.