Coding Challenge 1: Exploring Algorithms

Assigned
Friday, 5 September 2025
Summary
For this assignment, you will identify the parts of an algorithm, find some problems with that algorithm, and write an improved version. You will then design some of your own algorithms in Scheme.
Collaboration
You must work individually on this assignment. You may only consult members of the course staff for help.

Instructions

In this first coding challenge you should create a file called exploring-algorithms.scm which will contain all of your answers and code for this assignment. Use comments to organize your file so it’s easily read by a human.

At the top of your file, make sure to include your name, and any acknowledgements according to our collaboration policy. In that vein, now is a great time to review those collaboration policies!

If a problem asks for a written response as an answer, use a comment to include it in your code file. Make sure to name definitions exactly as prescribed in the problems.

Problem 1: Recipes as algorithms

Human beings write algorithms for a wide variety of activities; not just computation by electronic digital computers. One of the most common kinds of algorithms we write are recipes, which are most typically implemented by other human beings.

a. Find an interesting recipe. Copy and cite that recipe.

b. For that recipe, list the parameters and variables.

c. For each parameter, list any implicit or explicit limitations on the input. For example, if you say that “flour” is an input for your recipe, must the flour be wheat flour, or will rice flour do?

d. For that recipe, indicate any situations in which repetition and conditionals are used. (If neither repetition nor conditionals are used, indicate how the recipe might be extended to include repetition or conditionals.)

e. For that recipe, indicate what basic operations or subroutines the recipe author assumes that the reader already knows how to do.

f. Most recipes are written for “average” cooks. Either rewrite the algorithm for a beginning cook or write a detailed set of instructions for one of the “assumed knowledge” subroutines of the algorithm.

Problem 2: Timestamps

Many computers, including those on MathLAN, represent time as the number of seconds elapsed since midnight on January 1, 1970, a time known as the UNIX epoch. We’ll use these timestamps to compute the day of week from a timestamp.

We will represent days of the week with integers; Sunday is represented by 0, Monday by 1, Tuesday by 2, and so on until Saturday, which is represented by 6. January 1, 1970 was a Thursday (or a 4 in our representation). Write a series of definitions that assign the variable day-of-week to be the day of the week for the day represented by the time in the variable timestamp.

Submit at least four example dates to show that your code works correctly. Here is one such example (which you may include in your four examples):

; This timestamp is for 12:00am GMT on May 25, 1977, the original release of Star Wars Episeode IV
; This day was a Wednesday
(define timestamp-1 233366400)

; You may want to include intermediate definitions here to make your final expression simpler

(define day-of-week-1 ...)
; day-of-week-1 should now be define to 3, which represents Wednesday

You may find the website http://www.timestampgenerator.com useful for creating test cases.

Note: You may ignore complicated time and date issues like time zones and leap seconds in your day calculations. To make sure your answers are correct, I recommend choosing times in Greenwich Mean Time.

Problem 3: Scoring athletes

As you may know, in many sports, such as diving and gymnastics, a group of judges award scores to each athlete. To improve the accuracy of the scoring, they normally drop the top and bottom score and then compute the average. (Yes, there are many variants of this approach.) We’ll call this a robust average.

In this problem, we will work incrementally to build some portions of a program that calculate an overall score from several judges for a athlete’s performance.

Furthermore, we want the output to be easily readable and meaningful, so we will do some numeric processing to convert the precise scores into something more humanly intelligible.

First, copy the following definitions into your .scm file.

(define judge1 7)
(define judge2 10)
(define judge3 5)
(define judge4 8)
(define judge5 6)
(define judge6 9)
(define judge7 8)
(define judge8 6)

a. Write the following defintions.

(define total-score ...)
(define average-score ...)
(define lowest-score ...)
(define highest-score ...)
(define robust-average ...)

The total-score should be the sum of all the scores. Note that total-score should remain correct, even if we change the values associated with judge1. The average-score is the average computed in the usual way. The lowest-score is the lowest value from the eight judges, and similarly for the highest-score. Finally, the robust-average is the average of the scores after dropping the highest and lowest scores.

b. The averaged scores you may have seen so far may not be all that pretty. For example, we might prefer 7.3 instead of 7.33333333….., (the decimal representation of 22/3).

You may recall that we have a number of mechanisms for rounding real numbers to integers, such as ceiling and floor. But what if we want to round not to an integer, but to only one digit after the decimal point? Scheme does not include a built-in operation for doing that kind of rounding. Nonetheless, it is fairly straightforward.

Add instructions to your program that calculate a version of robust-average rounded to the nearest tenth.

Now, let’s generalize your instructions to round to an arbitrary number of digits after the decimal point. Suppose precision is a non-negative integer and robust-average is the value you computed above. Write another set of instructions for rounding robust-average to use exactly precision digits after the decimal point.

> (define precision 3)
> (*your-instructions* ... robust-average ... precision ...)

As you write your instructions, you may find the expt function useful. (expt b p) computes bp.

Submission guidelines

Submit exploring-algorithms.scm on Gradescope.

Grading rubric

In grading your submission, we will look for the following at each level. Note that if a criteria does not pass a lower level, we will likely not check for criteria at the higher levels. We may also identify other characteristics that move your work between levels.

You should read through the rubric and verify that your submission meets the rubric.

Redo or above

Submissions that lack any of these characteristics will get an N.

[] Includes the specified file (correctly named).
[] Includes an appropriate header on the file that indicates the course, author, acknowledgements, etc.
[] Acknowledges appropriately.
[] Code runs in scamper.

Meets expectations or above

Submissions that lack any of these characteristics but have all the prior characterstics will get an R.

[] In problem 1, all answers are reasonable or reasonably justified.
[] In problem 2, days of the week are calculated correctly.
[] In problem 2, at least 4 example dates are given.
[] In problem 3a, all values are computed correctly.
[] In problem 3a, computations are done in a way that will update if the judge scores are changed.
[] In problem 3b, expressions round correctly.

Exemplary/Exceeds expectations

Submissions that lack any of these characteristics but have all of the prior characteristics will get an M.

[] Code is well formatted with appropriate indentation.
[] In probelm 1, part f is especially detailed and easy to follow for someone new to the kitchen.
[] In problem 3b, `precision` is defined and used in later computations where appropriate.