BFOIT

  Introduction to Programming 

Procedure Inputs
and Pixels

Introduction

As you've discovered by now, programming involves describing how to do something as a series of steps.  Since most programs are too complex to simply type-in, you use procedural abstraction.  You break the problem that you are trying to solve into pieces.  Each piece is represented as a procedure which you define.  Your procedures are simply lists of TurtleTalk instructions.  In technical terms, you are using abstraction to make your programs easier to understand and thus easier to write correctly and enhance.

As you think about the steps or as you are typing in TurtleTalk instructions, you will recognize similarities or patterns in your code.  When you discover a pattern with the same instructions being used over and over again, you can reduce the total amount of code by using iteration in the form of the repeat command.  This makes your program smaller making it easier to understand, thus reducing the chances of making mistakes.

But, iteration only lets you eliminate duplicated TurtleTalk instructions, identical code.  In this lesson, you'll learn how to make your procedure definitions more applicable by specifying that they expect inputs, also known as parameters.  These inputs (their names) are used in the body of the procedure in the place of specific (actual) values.  Each time you invoke the procedure, you provide a specific (actual) value to use in place of the input, where its name is in the body of the procedure.

Procedures with inputs allow you to reduce multiple, similar, patterns of instruction sequences to a single instruction.  Confused?  It will become clearer as this lesson progresses...

Similar, But Different, Boxes

Look at the series of objects in Figure 5.1.  What are the similarities of the objects?  What are the differences?  Take a moment to write your thoughts.

Figure 5.1

Now, start with the top row of boxes.  Write a TurtleTalk program which draws the series of growing boxes.  Your program should consist of a procedure for each box.  Then, write a procedure with the name "main" which contains invocations of these procedures.  Finally, invoke "main" to display the row of boxes.

If you need to refresh your memory regarding procedures, review procedure definitions and procedure definition vs invocation.

Similar Procedures

Here are my definitions of the procedures which draw the first couple of boxes and part of the definition of my main procedure. 


    to box25
      repeat 4 [forward 25 right 90]
      end

    to box50
      repeat 4 [forward 50 right 90]
      end

    to main
      pu setx -250 sety 12 pd
      box25
      pu setx -200 pd
      box50
      ...
      end

Since the procedures draw different sizes of boxes, I've given them different names.  But, the only difference in the instructions that make-up the body of these procedures is the number of steps that the turtle is told to move forward. 

Think about this scenario.  TurtleTalk doesn't have an infinite set of forward commands, e.g., "fd25," "fd50," "fd75," etc...  There are not commands for all possible right instructions, e.g., "rt30," "rt45," "rt90," etc...  There are commands "forward" and "right" which expect an input that specifies the number of steps to move, or the number of degrees to rotate.

We obviously need the ability to define procedures in a similar manner.  We need the ability to define a procedure named box that expects to get a number when it's invoked.  The number will determine the size of each side of the box we draw.

What we need is called an input.

Defining a Procedure With an Input

Here is what we want... 


    to box :size
      repeat 4 [forward :size right 90]
      end

This procedure definition has an input.  Similarly to the way you name the procedure itself, you give the input a name, an identifier.  In this example, I've chosen the name size.  The colon preceding the name (pronounced "dots") tells the interpreter that this word is an input and that it should use what's in it. 

What do I mean, in it?  Well, an input is one kind of a thing that's called a variable.  Variables are containers.  Inputs get a value put in them when the procedure they are part of is invoked.

Up until now, all of the TurtleTalk programs you've written have been composed of commands with literals as arguments.  Literals are constants like the number "4" in the repeat instruction in the example above.  Every time box is invoked, the <List-of-Instructions> input to the repeat command is performed 4 times. 

But now, the input to the forward command is a variable - the input named size.  The number of steps that the turtle moves forward is equal to the input provided in an invocation of box.  The turtle moves a variable number of steps everytime the TurtleTalk interpreter performs the box procedure.

Here's the TurtleTalk interpreter in applet form.  Type in the example definition of box from above and then invoke it a couple of time with different values as arguments, e.g., 


    box 10
    box 25
    box 100

Then, see what the following repeat instruction does... 


    repeat 4 [ box 25 box 50 box 75 left 90 ]

alt="Your browser understands the <APPLET> tag but isn't running the applet, for some reason." Your browser is completely ignoring the <APPLET> tag!
TurtleGraphics Applet

Procedures With Multiple Inputs

So, you've reduced the number of procedures for drawing your boxes from five to one.  Very nice.  But, if we look at the commands remaining which display the line of boxes, you should see a pattern.  Here is my modified main procedure which draws the line of boxes. 


    to main
      pu setx -250 sety 12 pd
      box 25
      pu setx -200 pd
      box 50
      pu setx -125 pd
      box 75
      pu setx -25 pd
      box 100
      pu setx 100 pd
      box 125
      end

I instruct the turtle to pick up the pen, move to the location of the lower-left corner of a box, and then lower the pen.  All of these instructions can be moved inside the definition of box - if... you add inputs for the X and Y coordinates.

Modify your box procedure so that it has three inputs: the location of the box (the X and Y coordinates of its lower-left corner) and its size.  Then, in the body of box, use the setx and sety commands along with the X and Y coordinates that are now available as inputs.

Oh - I guess I snuck a couple of new commands in on you.  You haven't seen setx or sety (unless you've visited Appendix B).  The setx and sety commands move the turtle to specific coordinates in TurtleSpace.  They take an integer as an input, which is the point to go to.

Anyhow, once you have made your changes, test what you came up with by trying the following procedure invocations. 


    box -250 12 25
    box -200 12 50
    box -125 12 75
    box -25 12 100
    box 100 12 125

Stop reading until you've tried coming up with something.

The most important thing to get correct (and learn from this exercise) is the order in which your inputs are provided when you invoke the procedure.  The actual values for the X and Y coordinates and the size must be provided in a matching order with the inputs in the procedure definition.  Specifically, if your definition of box started out: 


    to box :size :xCoord :yCoord

the test invocations I asked you to try would not do what I was expecting.  The test invocations expect :size to come last.

But, other than this gotcha, multiple inputs are as easy to use as single inputs.

TurtleTalk Animation

Here is a small TurtleTalk program which draws three cubes.  Watch how the program is executed, step by step.  Especially watch how how the inputs change when the procedures are invoked.  As an example, when diamond is invoked, its :steps variable is replaced with a number.

alt="Your browser understands the <APPLET> tag but isn't running the applet, for some reason." Your browser is completely ignoring the <APPLET> tag!

The Turtle's Pen (Pixel Graphics)

I'm not going to give you the solution for the boxes program you are writing, but I'll help you get one step closer.  In this section, I'll tell you a little more about how the turtle draws. 

Since our turtle lives inside a computer, the space it draws on is your computer's display.  For you to get the turtle to draw more interesting things, like the solid colored boxes in this lesson's exercise (Figure 5.1), you need to know a little more about computer displays. 

A computer display is made up of a bunch of dots, called pixels, (an abbreviation for picture elements).  The pixels are objects arranged in rows and columns, each spaced an equal distance from the others.  Each pixel has a value assigned to it which is its color.  Back in the first lesson, you got to interact with an applet that demonstrates color values.

So, Figure 2.1 is a nice, abstract, view of our turtle's world, but here is a more accurate picture:

Figure 5.2

To display a thin vertical line, the color values of a column of pixels are set to the desired color of the line.  If you want a thicker vertical line, you set the color values of the pixels of a group of consecutive columns to the desired color.  Figure 5.3 shows a red line that's a single pixel wide and an orange line that's three pixels wide.  The orange line is actually a very thin rectangle.

Figure 5.3

There are no TurtleTalk commands that let you modify pixels, but the pen that the turtle carries changes pixels as it passes over them.  You control the color the pixels get set to with the setpencolor TurtleTalk command.  You also can control the width of the line that the turtle draws with the setpensize TurtleTalk command. 

So, the colored boxes that you need to draw to complete this lesson's main exercise are nothing but rectangles of pixels.  How you set them is up to you.  Remember back in the lesson where I introduced iteration?  We drew points that were actually boxes.  There's another way to create a solid colored box using lots of single-pixel-wide lines.  It's now up to you to figure out how to do it.

Final Challenges

Time to finish your program which draws a series of boxes that grow in size.  You now should be able to write a procedure which draws a solid colored box.  Do it!  And, then use it to complete your program for Figure 5.1. 

If you are having trouble getting started, refer back to the steps for writing programs that were described in the lesson which introduced procedures.  Start by writing everything you know about what needs to be done.  Convert this into pseudo-code.  And, then, figure out how to translate this into TurtleTalk...

Additional Exercises

  1. Your boxes are squares which are special cases of rectangles.  Write a couple of procedures that draw rectangles.

    1. One, rectangle, should take four inputs: a starting position (xPos and yPos), a width and a height and produce a wire-frame rectangle.

    2. The other, filledRectangle, should take the same four inputs and produce a solid-colored rectangle.

    Once you've tested them and they are working, modify your box procedure and the one you wrote which produced solid-colored boxes to invoke your new rectangle and filledRectangle procedures instead of directly manipulating the turtle.

  2. It is common to add a shadow to an object in computer graphics.  Figure 5.4 shows an example of a box with a shadow.

    Figure 5.4

    Modify your program to add shadows to all of your colored boxes.

  3. The exercise at the end of the last lesson challenged you to take something as simple as an arc and use it to draw a flower (see Figure 4.1).  Here is a simple seascape that is also composed with arcs. 

    Figure 5.5

    Write procedures arc, bird, fish, and waves and then invoke them from a main procedure.  Then invoke main to draw your seascape.

Summary

In this lesson, you've learned how to extend the utility of procedures.  You now know how to write procedures that can act differently; exactly what gets done depends upon the inputs ( parameters) that are provided in invocations.  This is good for two reasons:

  1. You can reduce the size of your programs.  The shorter your programs are, the easier they are to read and understand, the less chance they have mistakes in them, and the less you have to type.

  2. Your abstractions can be more powerful.  Without inputs, a procedure does the same thing every time it is invoked.  This is pretty limiting.  But, with inputs, your procedures are much more flexible.

New TurtleTalk Procedures Used In This Lesson
Name Input Description Example
SETX  number Moves the turtle horizontally to the specified absolute window position. SETX 100
SETY  number Moves the turtle vertically to the specified absolute window position. SETY 100

Back to Table of Contents
Back to previous Lesson ( TurtleTalk Iteration )
On to next Lesson ( TurtleTalk Operators & Expressions )