Definitely avoiding repetitions

In this lesson, we will learn how to define some new robot commands. We will also see a third useful rule when writing computer programs:

Rule # 3
When writing computer programs, do not repeat yourself.
I repeat: do not repeat yourself!

1. Three lefts can make a right

If you think carefully about it, you will conclude that having Reeborg make three left turns in a row gives the same final result as if he were to make a single right turn. Try to figure out, by drawing on a sheet of paper, what the following program would have Reeborg do, without using your computer.

turn_left()
move()
turn_left()
turn_left()
turn_left()
move()
move()
turn_left()
turn_left()
turn_left()
move()
turn_left()
turn_left()
turn_left()
move()
move()
turn_left()
turn_left()
turn_off()

Your turn

Write and save the program above, and see if Reeborg does what you expected him to do.

Your turn again!

Change the program you just saved so that it will make Reeborg turn clockwise around a square as illustrated below.

square with right turns


2. Defining what is right

We have seen before how Reeborg can make a right turn by combining three left turns in a row. If we want to make a series of right turns, it becomes quite tedious to write and read the resulting code. This is because we repeat ourselves; in other words, the same sequence of instructions appears in many different places in the program. To avoid such duplication, Reeborg's ability to be programmed in Python is very useful.

In Python, one can give a simple name to a series of instructions. For example, we could define a right turn command for Reeborg as follows:

defining turn right

Four important things are to be noted:

This is quite a bit of information presented all at once. It is probably a good time to check your understanding of how to use this keyword.

Your turn

Write a program that 1) defines this new command to turn right and 2) makes use of it to have Reeborg trace a clockwise square as done previously. You should notice that the final program is shorter than the original and that it is easier to figure out the path taken by Reeborg.

Your turn again!

Define the instruction step_back() so that the following program

# step_back() defined up here
move()
step_back()
turn_off()
has Reeborg take a step forward and then come back to its starting position facing in the same direction as it did at the beginning, as illustrated below.

back up

Hint: Make sure you don't forget to indent the commands that are part of your new definition.

Your turn, yet again!

Define the instruction turn_around() so that the following new commands would work as you expect them to.

def step_back():
    turn_around()
    move()
    turn_around()

def turn_right():
    turn_around()
    turn_left()

3. Newspaper delivery, revisited

In the previous chapter, one of the last exercises you had to do was to write a program to have Reeborg deliver a newspaper. As a reminder, here's graphically what Reeborg had to do:

newspaper start
lead to newspaper end

Your solution to this exercise probably looked like the following

move()
# climb step
turn_left()
move()
turn_left()
turn_left()
turn_left()
move()
move()
# climb step
turn_left()
move()
turn_left()
turn_left()
turn_left()
move()
move()
# climb step
turn_left()
move()
turn_left()
turn_left()
turn_left()
move()
move()
# climb step
turn_left()
move()
turn_left()
turn_left()
turn_left()
move()
move()
# put down newspaper and turn around
put_beeper()
turn_left()
turn_left()
# step down
move()
move()
turn_left()
move()
turn_left()
turn_left()
turn_left()
# step down
move()
move()
turn_left()
move()
turn_left()
turn_left()
turn_left()
# step down
move()
move()
turn_left()
move()
turn_left()
turn_left()
turn_left()
# step down
move()
move()
turn_left()
move()
turn_left()
turn_left()
turn_left()
# move away and stop
move()
turn_off()

That's a lot of typing ... and there is a lot of repetitions. By the time you reached the end of the program, you can't see the beginning of it on the screen. You probably noticed that I added a few comments which helped me to keep track of where I was in the task. These comments are closer to what we could think of when coming up with the outline of a solution:

Let us try to write this outline in a Pythonic form:
 
climb_up_four_stairs()
put_beeper()
turn_around()
climb_down_four_stairs()

This is not quite a complete solution [for example, there is a missing turn_off() instruction], but it is pretty close to it and is much easier to read than what we had before, assuming that these new instructions are defined. Here's a few of the needed definitions:

def turn_around():
    turn_left()
    turn_left()

def turn_right():
    turn_left()
    turn_left()		
    turn_left()

def climb_up_one_stair():
    turn_left()
    move()
    turn_right()
    move()
    move()

def climb_up_four_stairs():
    climb_up_one_stair()
    climb_up_one_stair()
    climb_up_one_stair()
    climb_up_one_stair()

Your turn

Add the missing definitions so that the final program looks like what I called the Pythonic version. You will need to add a few more simple instructions, including turn_off() at the end. Remember to save your program; use a different name from your original solution.

Your turn again!

Take the time to compare your original solution to the newspaper delivery program as well as this latest one. Which one is the easiest to read?


4. Reading challenge

Well chosen names can really help to understand what a program is doing. Likewise, poorly chosen names can make it really difficult. [See Rule # 4.] Try to make sense of the following program without using the computer to run it.

def a():
    turn_left()
    turn_left()

def b():
    turn_left()
    a()

def c():
    move()
    move()

def d():
    c()
    b()

def e():
    d()
    d()
    d()
    d()

turn_left()
e()
b()
turn_off()

You may find it useful to find more descriptive names for the commands a(), b(), c(), d(), and e().

previous Building walls - home - Avoiding repetitions, again! next
../images/SourceForge.net Logo