CS 368-1 (2011 Summer) — Day 14 Homework

Due Thursday, August 4, at the start of class.

Weather Forecast Analysis, Part III

The purpose of this three-part project is to compare weather forecasts against actual weather observations. In this third and final part, the goal is to do the comparisons and print a textual report of the findings.

Details

We have daily forecast data. We have hourly observation data. Now we want to make a report that looks like this:

On July 29, the high was forecast to be in the upper 80s and the actual
high was 86.5F, 0.5F lower than predicted; the low was forecast to be
in the lower 60s and the actual low was 71.2F, 8.2F higher than
predicted.

On July 30, the high was forecast to be in the upper 80s and the actual
high was 88.1F, as predicted; the low was forecast to be in the upper
60s and the actual low was 72.1F, 3.1F higher than predicted.

On July 31, the high was forecast to be in the upper 80s and the actual
high was 89.1F, 0.1F higher than predicted; the low was forecast to be
in the upper 60s and the actual low was 74.7F, 5.7F higher than
predicted.

Skipped 2011-08-01: Only 7 hours of data

Skipped 2011-08-02: No actuals found

The starting script is available here.

As always, there are some challenges to this assignment:

• Our forecasts are strings like “AROUND 70”, “LOWER 70S”, “MID 80S”, and “UPPER 80S”. But to compare our actual highs and lows to these forecasts, we must convert the textual descriptions into a range — that is, a minimum and maximum forecast temperature. You will do this in the compute_forecast_range() subroutine. The comment block preceding that subroutine gives examples of the numeric ranges to use for each type of prediction. For example, we want to convert “UPPER 80S” to the range [87.0, 89.0].
• We have actual observations of temperatures (minimum and maximum) for each hour. But which observations should we examine for a given day’s forecast? For example, suppose we are analyzing the daily forecast issued at 6:47 a.m. on July 29; it predicted a high “in the upper 80s” and a low “in the lower 60s”. When would that high occur? As it happened, the high was 86.5°F during the 6 p.m. hour. And the low? 71.2°F during the 5 a.m. on the next day, July 30. So, I made the design decision to examine actual observations for a day from noon on that day until the 11 a.m. hour on the following day. While not defensible in the long run, it is adequate for this exercise. Furthermore, you do not really have to worry about it too much, because I am giving you the subroutine that finds the actual high and low for each forecast date.
• For each day, we have a single sentence that is the report for that day. It contains a repeated section of text, once for the forecast high and once for the forecast low. Hmmm… repeated output formats… what should we do about that? Of course: Write a subroutine! And in fact, you will write this subroutine, named report_temperatures(). It takes a string indicating the type of forecast (literally, “high” or “low”), the forecast string (e.g., “UPPER 80S”), and the actual corresponding high or low. It should return a fragment of the report, “the [high/low] was forecast to be … predicted”. See the comment block preceding the subroutine for more examples.
• The final report consists of a lot of long sentences. Let’s imagine that we are going to email this text to someone, and we want to keep each line of text within 72 characters. How do we do this, for all lines of the report? You tell me, specifically in the print_report() subroutine. Hint: My solution took only a line or two of code, so this should be fairly easy.

Optional Work

• Write unit tests for the code. I tried to design most of the subroutines to be good for testing. And you have now seen the Test::More pattern a few times, so you should be able to write some tests.
• If you want to make the assignment a bit more challenging, simply delete the contents of any other subroutines in the script, and try writing them yourself.
• If you like, you are welcome to write the entire script on your own.

Reminders

Do the work yourself, consulting reasonable reference materials as needed; any reference material that gives you a complete or nearly complete solution to this problem or a similar one is not OK to use. Asking the instructors for help is OK, asking other students for help is not.

Hand In

A printout of your own portions of the final script, ideally on a single sheet of paper printed on both sides; if you need to have multiple pages, that is OK. Be sure to put your own name in the initial comment block of the code. Identifying your work is important, or you may not receive appropriate credit.