Mini-Project 1: Playing with image composition and decomposition

Summary

In this assignment, you will explore the value of open exploration (which my colleague Peter-Michael Osera calls “playing around”) when learning how to program.

Collaboration

Each student should submit their own responses to this project. You may consult other students in the class as you develop your solution. If you receive help from anyone, make sure to cite them in your responses.

Mini-Project 1 : Playing with image composition and decomposition

In the first few days of class, you have received a crash-course introduction to programming in Racket, in particular with images. Furthermore, you also learned about algorithmic decomposition and its importance in computer programming. In this brief demonstration exercise, we’ll practice these techniques further by playing around with images.

External and internal correctness

In this course, we’re concerned about writing good code. What does that look like? Good programs have two qualities we’re looking after:

• External correctness: Does the program behave correctly according to its specification?
• Internal correctness: Is the program designed well?

External correctness is observable in the sense that we can run a program and determine that its behavior is correct. In contrast, internal correctness concerns the design of our program: Is it readable? Does it follow the design guidelines outlined in the exercise write-up and otherwise adhere to good coding conventions?

External correctness is often a given—we always want to write programs that do the right thing. However, we’ll find in this course that internal correctness is just as important! Computer programs are not just “consumed” by computers Other people will read and even modify our programs. In particular, you will find that in three months (or perhaps sooner), you will feel like “another person”, forgetting what you were thinking when you were designing the program. So it is important that we build habits that are conducive to writing readable code.

Playing around

As we discussed previously, programming is not a spectator sport (really, few things are in this world). You need to write programs to learn how to program. You often need to write programs to learn to think computationally. The labs and projects will be you primary vehicle for this sort of practice. This alone may be enough for some of you to master Racket programming. But for many people, you will need additional practice to truly master these concepts.

One way to do this is through “playing around.” What we mean by this is programming for the purposes of exploring a programming language or its libraries, rather than a specific end-product. This is how many of us approach learning a new language. We may have a few starting points in our back pockets, but as we write, we are less concerned about finishing the task at hand as we are about understanding the new environment. This exploration usually involves investigating and answering questions such as “How do I do X in this language?” or “How does feature X that I don’t understand compare to feature Y that I do understand?” or even “How does this language lead me to think differently about algorithm design?”

Because you are beginning programmers, your questions will likely be markedly simpler: “How can I even make a thing happen?” Hnd “how do I type a thing?”. But nevertheless, “playing around” lets you tackle some of those ideas. You might start with one our lab exercises that you developed with a peer as a starting point and then change the code in ways that are novel to you. Or you might start from scratch and try to reproduce something you have seen or written before. There is no right way to go about “play”. Its the attitude that’s important: one of exploration and asking and answering questions rather than focusing on the final product.

Turn-in details

For this demonstration exercise, write your Racket program in a file called play-around.rkt and submit it to Gradescope. For additional details on turning on this assignment and interpreting your feedback from it, please consult the Gradescope page.

Part 1: Rainbow spaceship

For this first part of the demo, your goal is to define an image called rainbow-spaceship that looks like this:

Here are the details of the rainbow-spaceship image:

• The spaceship composed of a collection of colored stripes, each of which are 100 pixels wide and 25 pixels tall.
• As the spaceship grows in height from left to right, a new colored stripe is added in rainbow order from top to bottom. The order of colors of the rainbow are red, orange, yellow, green, blue, and violet.
• The spaceship then shrinks in height past its center-point, losing a stripe from bottom-to-top order.

The “horizontal pyramid” effect is due to how the image library places sub-images with beside when they are different heights. Smaller images are automatically centered vertically relative to the taller images. For example the left-most red stripe is vertically centered relative to the red-orange two-stack of stripes next to it.

Make sure that the definition of rainbow-spaceship mimics its structure. Also pay special attention to remove redundancy from your code using define and, as appropriate, functions. We do not yet have the machinery to elegantly capture the growing, symmetric nature of the columns of the spaceship. However, note the relationship between the stripes of each successive column. How can you capture this relationship in code?

Part 2: Freestyle

Now that you’ve had a taste for manipulating images and using define and functions to reduce redundancy, you will now get the opportunity to play around making images of some complexity. As discussed, this is open-ended: I have no particular image for you to draw and only some requirements about how you design your program. Feel free to try the following starting points:

• Take our image drawing lab and improve on the pictures there.
• Find an image on the Internet and do you best to replicate it using the limited image functions we’ve discussed in the course. Keep in mind that your final image will likely be impressionistic in nature!
• Doodle! Start with a few shapes and try to build up interesting patterns from there.

To encourage you to practice algorithmic decomposition, your program must follow these design requirements:

• Your image should contain no fewer than five smaller sub-images that you identify and codify in your program using the define command.
• Your image should employ at least one function that has at least one parameter that is employed in cutting down the code redundancy of your image in some way.
• The names you define should be evocative of what the image is. It should be pithy, a few words at most, but at the same time descriptive. Racket programming conventions say that these names should be in all lowercase with dashes between words, e.g., names-like-this.

• Your program should include a define that is the overall image. In a comment at the top of your file, you should identify which define is the overall image, e.g.:

  # lang racket
  
  (require 2htdp/image)
  (require csc151)
  
  ; My overall picture is a mountain defined to be `my-mountain`.
  
  ; (...code below here...)
  ;
  ; (define my-mountain ...)
  

Other than this, there are no minimum requirements regarding limits, code size, or complexity. Have fun with it!

A note on additional complexity

You are under no obligation to use additional functions or language features beyond what we have introduced in this first week. However, You may feel limited by the functions we have discussed so far. If so, you are free to reference the documentation for the 2htdp/image library for the full set of functions available:

• 2htdp/image library

Note that this documentation may not be entirely comprehensible to you yet! That is fine. If you choose to explore this library in more detail, I recommend experimenting with these functions in the interactions pane and figure out how they work before throwing them into your code. Remember, if you adapt any code from this library’s documentation, you should cite that you did so in a comment in your code!