Homework 4🔗

Last updated: Fri, 11 Oct 2024 15:32:27 -0400

Out: Mon Sep 30, 2024, 12pm (noon) EST

Due: Mon Oct 07, 2024, 12pm (noon) EST

Overview🔗

This assignment continues to explore programming according to the The Design Recipe, a systematic way to write programs that are both correct and readable.

In particular, this assignment will focus on Data Definitions involving Arbitrarily Large Data and lists.

This hw will be graded accordingly:

Setup🔗

Create a new repository for this assignment by going to the CS450 Fall 2024 GitHub Organization and clicking "New".

Note: The CS450 Fall 2024 GitHub Organization must be the owner of the repository. Do not create the repository in your own account.

When done click "Create repository".

Tasks🔗

Reading

• Read Chapters 8-9 of the Textbook (where reading means working through the examples and exercises interactively).

• Review the The Design Recipe section of the course website (topics that will be covered in future lectures are marked as such).

Notes and Reminders

• All code you write must now follow the The Design Recipe. (Just submitting code is no longer sufficient.)

• Signatures should use define/contract and the predicates defined in the Data Design Recipe step. UPDATE: You may need the listof contract constructor for this assignment.

• For Examples and Tests, do not use check-expect from the Beginning Student Language (even though the textbook says to). Instead, use check-equal? or other testing forms from rackunit.

• Examples for a function definition should come right after the define. But Tests should be put into the test-suite in tests.rkt. Try to think about corner cases and code coverage.

• Also, remember that Racket Style and The Design Recipe reserves certain language features only for specific scenarios. For example, set! and other "imperative" features are not allowed ever. Conditionals such as cond should only be used with enumeration or itemization Data Definitions.

• The submitted program must be only a series of defines (both constants and function definitions are allowed) and tests/examples. Do not run any other code, i.e., do not automatically start big-bang! Not following this this will result in GradeScope errors and point deductions.

• You may look at prior code and examples to help you but BE CAREFUL. A "COPY-AND-MODIFY" PROGRAMMING STRATEGY WILL NOT WORK IN THIS COURSE (nor in the real world). Your program will be wrong (partially because most of the design recipe steps will be wrong) and will receive a low score. Instead, you should write the code for this homework from scratch using The Design Recipe.

Programming

In this assignment (and the next one or two) we’ll continue building our "Guitar Hero"-like big-bang interactive program.

Here is an online demo that approximates what the program might look like (after the next few weeks).

The main code should go in a file named hw4.rkt and tests should go in a tests.rkt file of the appropriate format.

In this assignment, each function should have at minimum of one (meaningful) Example and two Tests (that are not the same as the example).

• This assignment will focus on writing functions that process recursive list Data Definitions. (Subsequent assignments will put them together into a full program.)

• Specifically, we’ll work with the following Data Definition for a "Note":

  ;; A Note is a (make-Note [y : YCoord] [vel : Velocity] [state : NoteState]) where

  ;; y : represents y coordinate of note center

  ;; vel : velocity of note on y axis (positive = down)

  ;; state : state of the note, e.g., "hit" or "missed"

  (struct Note (y vel state) #:transparent)

  (define/contract (make-Note y vel state)

  (-> YCoord? Velocity? NoteState? Note?)

  (Note y vel state))

  For now, assume that the y coordinate is a non-negative integer and velocity is an integer between 1 and 10.

• A Note requires a NoteState:

  ;; A NoteState is either:

  ;; - PENDING

  ;; - HIT

  ;; - MISSED

  ;; - OUTOFSCENE

• Complete the NoteState data definition by adding an interpretation, and define the appropriate constants and predicates.

• Now write the following functions that process a Note

  • next-Note : Will be called on each tick to update the note. The note should advance according to its velocity. For now the NoteState will not change.

  • out-Note? : returns true if the given note is OUTOFSCENE

  • place-Note-in-scene : takes a Note and a htdp image? and draws the Note, using make-Note-image (see below), into the scene at its y coordinate and some SCENE-CENTER-X constant.

  • overlap? : takes two Notes and returns true if they overlap

  • make-Note-image : takes a NoteState and returns an image? as follows:

    • PENDING : solid green circle of NOTE-RADIUS

    • HIT : solid blue star-polygon with side-length = NOTE-RADIUS, 8 sides, and step-count 3

    • MISSED : outline red circle with radius NOTE-RADIUS

    • OUTOFSCENE : unspecified

• Now consider the following Data Definition for a list of Notes:

  ;; ListofNotes is either

  ;; - empty

  ;; - (cons Note ListofNotes)

  ;; Interp: represents a set of Note instances

• Define a function Notes? that consumes any list and checks whether every element of the list is a valid Note?

• Now write the following functions that process ListofNotes:

  • prune-Notes : takes a ListofNotes and removes the ones that satsify the out-Note? predicate

  • next-Notes : take a ListofNotes for each, computes the updated notes after one tick

  • place-Notes-in-scene : takes ListofNotes and a image? and inserts the notes into the scene using place-Note-in-scene

  • maybe-add-Note : takes a list of notes and inserts a new note at the front of the list at coordinate NOTE-INIT-Y and some constant NOTE-VELOCITY and PENDING state if

    • a 1-in-100 random function, called insert-note? returns true

    • the new note would not overlap with the note that is closest to the top in the given list

    Since this function processes randomness, it may use if, but no more than two.

• For the constants referenced above, define and provide the following:

  Constants

  • SCENE-HEIGHT = 400

  • SCENE-WIDTH = 400

  • SCENE-CENTER-X = 200

  • NOTE-RADIUS = 20

  • NOTE-INIT-Y = 0

  • NOTE-VELOCITY = 4

  • PENDING

  • HIT

  • MISSED

  • OUTOFSCENE

Before Submitting🔗

Testing

Style

All code should follow proper Racket Style.

Also, the repository itself must follow proper style. Specifically, it must have appropriate commit messages. See How to Write a Git Commit Message if you are unsure how to write a commit message.

Files

A submission must have the following files in the repository root:

• hw4.rkt: Contains the hw solution code.

  All defines should use the name specified in the exercise (ask if you are unsure) and should be provided.

  The easiest (but not always the most readable) way to ensure all necessary definitions are provided is to (initially) put as the second line in the file:

  (provide (all-defined-out))

  This automatically provides all definitions in the file. (The first line should be #lang racket)

• tests.rkt: This file should require hw4.rkt and define tests for it.

  Specifically, it should define a rackunit test-suite which contains sufficient rackunit test cases (e.g., check-equal?, etc.) for each defined function.

• README.md: Contains the required README information, including the GitHub repo url.

Submitting🔗

When you are done, submit your work to Gradescope hw4. You must use the "GitHub" Submission Method and select your hw<X>-<LASTNAME>-<FIRSTNAME> repository.

Note that this is the only acceptable way to submit homework in this course. (Do not manually upload files and do not email files to the course staff. Homework submitted via any unapproved methods will not be graded.)