2014-01-30

Drawing a "tree burst" iteratively and recursively.


This week in class we examined a program that used turtles (in the Logo turtle graphics sense) to draw a simple fractal pattern we referred to as a tree burst. The goal was to get a better understanding of recursion by engaging it in a visual way. It worked well and I was able to intuitively grasp how the recursion was going to work a little faster than in a previous example using nested list objects.

The program (tree_burst.py) is available from the course website and its visual output is roughly similar to the image below.


After looking at it for a while it struck me that, since each line is drawn by its own turtle and that turtle remains at the end of the line until it's needed in the next level of recursion, it shouldn't be too difficult to get the same result using iteration. I gave it a shot and found that I was right. My iterative solution is somewhat less elegant than the recursive example but still concise enough to post here in full.

tree_burst_iterative.py

import turtle COLORS = ('red', 'green', 'blue') def tree_burst_iterative(level, length, turtle): '''Use copies of turtle to draw a symmetrical ternary tree fractile to the specified level of detail starting with initial lines of specified length. ''' turtle_list = [] turtle_list.append(turtle) for _ in range(level): new_turtles = [] for t in turtle_list: # Turn all existing turtles East and make them red. t.setheading(0) t.color(COLORS[0]) # For each existing turtle create two recolored clones facing NW # and SW respectivly. for i in range(1, 3): new_turtles.append(t.clone()) new_turtles[-1].setheading(120 * i) new_turtles[-1].color(COLORS[i]) # Add new clones to existing turtles and move all turtles forward. turtle_list.extend(new_turtles) for t in turtle_list: t.forward(length) # Halve the length of travel for the next round of moves. length = length / 2 if __name__ == '__main__': t = turtle.Turtle() t.speed('slow') t.color('red') tree_burst_iterative(4, 128, t)

Turtle image CC by jovian_dreams

2014-01-26

On object-oriented programming.


This sounds vaguely familiar.

I first encountered the concept of object-oriented programming in the late 1990s when I somehow acquired a copy of Practical C++ Programming by Steve Oualline. It was way beyond my computing knowledge level, I had written the tiny beginnings of a choose your own adventure style game in QBasic and was learning the basics of HTML, but I was enough of an enthusiast to slog through a good chunk of the book, even after realizing it wasn't anything I was actually going to use any time soon. The first thing I got out of reading about object-orientation, aside from new uses for words like class and parent, was the sense that programming was more complicated than I had thought. The second was that the architecture of programming was almost as much about making the workings of computers comprehensible to humans as it was about making computers do what we want them to.

Whence object-oriented programming?

The name object-oriented programming was coined by Alan Kay in the 1960s to describe the type of architecture he was working on while developing the Smalltalk language. The structure of Smalltalk was influenced by LISP, Sketchpad, and particularly Simula, which is considered an object-oriented language even though it predates the classification. Kay's central concept for object-oriented programming was that programs should be divided into distinct entities, like the cells of an organism or the separate computers in a network. These entities would protect their internal processes and data and would work together strictly by sending and receiving messages. In a 2003 email, Kay defined true object-orientation as "only messaging, local retention and protection and hiding of state-process, and extreme late-binding of all things." and added that he didn't think any languages besides Smalltalk and LISP existed that could meet this specification. It's interesting that Kay doesn't explicitly include either classes or inheritance, the concepts that most struck me on my first brush with C++, as important factors.

Object-orientation in Python.

Python is quite object-oriented in that everything in Python is an object or a label for an object (a variable). However, Python doesn't fit Kay's concept of object-oriented programing in at least one important respect: Python objects are almost entirely lacking in privacy. This means that, despite conventions such as special variable names to discourage taking indiscriminate advantage of this, all of a Python object's data and methods are generally directly accessible to the rest of the program. If the object architecture in Python is a code of etiquette then in a language like Smalltalk its a code of law. Smalltalk objects sit in separate cells passing notes under the doors while Python's inhabit a single room but, like polite guests at a fancy tea, they refrain from eavesdropping on neighboring tables... for the most part.

Image created from CC images by Ciro Cattuto and Scott Davies