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.
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
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
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.
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
If you like, you are welcome to write the entire script on your own.
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.
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.