CMSC 106

Project #2

Fall 2001

Due date: 11:00 pm on Monday, October 8, 2001.

1. Purpose

In this project you will write a program using various conditional statements.

For this project you will be writing a program that will help make local weather forecasts. The forecasts will be based on current barometric pressure, current wind direction, and the change in barometric pressure since the last observation.

2. Project description

As you read this section, you may also want to refer to the ``Sample output'' section below.

The input to be read and the output which should be produced is discussed below.

The program must first read the weather observation data to be used for the forecast. The data will be given to the program thorugh standard input redirection from an ASCII text file. As the programmer, you can assume the lines of the input file will be exactly as described here. You do no need to do any checking of the validity of the input.
1. The first line will contain the date and time of the CURRENT observation. The date will be of the form mm/dd/yy, where mm is the number of the month, dd is the day of the month, and yy is equal to the last 2 digits of a year in the range 1950 through 2049. The time will be of the form hh:mm, where hh is the hour and mm is the minute. The hour value will be given using a 24-hour clock, where hours 00-11 are AM and 12-23 are PM. All of the date and time values will be integers.
2. The second line will contain the barometric pressure in millibars and the wind direction. The wind direction will be indicated using an integer which corresponds to the layout of the numeric keypad on the keyboard:
  - 7 is NW
  - 8 is N
  - 9 is NE
  - 6 is E
  - 3 is SE
  - 2 is S
  - 1 is SW
  - 4 is W
  - 5 is calm (no wind)
  The pressure value will be an integer.
3. The third line will contain the date and time of the PREVIOUS observation. The date and time will be in the same format as described above for the current observation.
  NOTE: The date of the previous observation may not be the same as the date of the current observation. However, the observations will never be more than 24 hours apart.
4. The fourth line will contain the previous values of barometric pressure and wind direction. The format of these values will be the same as described above for the current observation.
The first line of the program's output must have the line "Current observation mm/dd/yyyy hh:mm", where mm, dd, yyyy, hh, and mm are the date and time values for the CURRENT observation. Each of the values for date and time must be printed using TWO digits, except for the year, which must be printed using FOUR digits in the range from 1950 through 2049.
The second line of the program's output must have the weather data read or derived from the input in the following order: (1) Barometric pressure - printed as a whole number of millibars followed by the word "millibars", (2) barometric tendency - printed as one of the phrases described under "Forecasting Rules" below followed by the actual rate of change in millibars per hour printed to a precision of 2 decimal places
The third line of the program's output must have the word "Wind" followed by the wind direction printed as one of the values NW, N, NE, E, SE, S, SW, W, or CALM
Following a blank line, the fourth line of output must have the word "FORECAST" preceded and followed by 4 asterisks.
The fifth line of output must display the forecast determined using the "Forecasting Rules" below. If it is not possible to determine a forecast using the values given, the word "Unknown" must be printed. Note that certain combinations of conditions are ambiguous. That is, they could produce two or more DIFFERENT forecasts. If this is the case, then NO forecast should be printed. Instead, the message "Forecast conditions ambiguous." must be printed.
The last line of output must say either that we are happy to provide this forecast using the exact word "happy" or that we are sorry we could not provide a forecast using the exact word ``sorry''.

2.1 Forecasting Rules

The forecast is based on the combination of current barometric pressure, barometric tendency, and current wind direction.
The barometric tendency is the rate of change of pressure, defined as follows in terms of millibars per hour (mb/hr):
1. If the pressure is rising or falling less than 1 mb/hr, then the tendency is "steady".
2. If the pressure is rising at least 1 mb/hr, but less than 2 mb/hr, then the tendency is "rising slowly".
3. If the pressure is rising at least 2 mb/hr, then the tendency is "rising rapidly".
4. If the pressure is falling at least 1 mb/hr, but less than 2 mb/hr, then the tendency is "falling slowly".
5. If the pressure is falling at least 2 mb/hr, then the tendency is "falling rapidly".
The forecast is determined according to the following conditions:
1. SW to NW, 1019 to 1023 and steady - Fair with no significant temperature change for 1 to 2 days.
2. SW to NW, 1019 to 1023 and rising rapidly - Fair; rain within 48 hours.
3. SW to NW, Above 1023 and steady - Fair with no significant temperature change for 1 to 2 days.
4. SW to NW, Above 1023 and falling slowly - Fair with slowly rising temperature.
5. S or SE, 1019 to 1023 and falling slowly - Rain within 24 hours.
6. S or SE, 1019 to 1023 and falling rapidly - Wind increasing, rain within 12 to 24 hours.
7. SE to NE, 1019 to 1023 and falling slowly - Rain in 12 to 18 hours.
8. SE to NE, 1019 to 1023 and falling rapidly - Wind increasing, rain within 12 hours.
9. SE to NE, 1016 or below and falling slowly - Rain continuing 1 to 2 days.
10. SE to NE, 1016 or below and falling rapidly - Rain and windy; clearing within 36 hours. (In winter, replace ``clearing'' with ``clearing and colder''.)
11. S or SW, 1016 or below and rising slowly - Clearing within a few hours then fair.
12. S to E, 1009 or below and falling rapidly - Severe storm, clearing within 24 hours. (In winter, replace ``clearing'' with ``clearing and colder''.)
13. E to N, 1009 or below and falling rapidly - Severe northeast gale and heavy precipitation. (In winter, replace ``heavy precipitation'' with ``heavy snow, followed by a cold wave''.
14. SW to NW, 1009 or below and rising rapidly - Clearing and colder.
Note: SW to NW means SW, W, or NW. SE to NE means SE, E, or NE. S to E means S, SE, or E. E to N means E, NE, or N.
Winter is defined as December, January, or February (months 12, 1, or 2). Conditions for winter should only be printed for forecasts made during these months.

3. Project requirements

All your C programs in this course should be written in ANSI C with trapping of unintialized variables, which means they must compile and run correctly with cc -std1 -trapuv on the OIT UNIX Class Cluster. Even if you already know what they are, you may not use any C language features other than those introduced in Chapters 1 through 5 of your textbook. Note that as a result loops, arrays, and user-defined functions may not be used. In addition, your program must contain only one single return statement at its end. Using C features not in these chapters will result in losing credit.

Your program must have a comment near the top which contains your name, login ID, student ID, your section number, your TA's name, and an original description of the action and operation of the program. Do not put your alias in this comment! Your program should be written using good programming style and formatting, as discussed in class and throughout your textbook. For this project, style is considered to consist of:

adequate descriptive comments throughout (in addition to the comment mentioned above), to describe what your program is doing and how
neat and proper indentation and formatting, including consistently and correctly aligning braces using any of the bracing styles illustrated in your textbook
writing clear and readable code
use of meaningful descriptive variable names
use of symbolic constants for all ``special'' values which don't change and which are used in more than one place in your code
avoiding disallowed C language features as discussed above

4. Developing your program

You may want to skip this section at first, read the rest of the project, and come back to study it carefully when you are about to begin writing your program.

4.1 Possible development steps

It is very important to continue to type in only a part of your program at a time and verify that it's correct, before going on. Any mistake is much easier to locate this way. The idea is that at all times you have a correct program, which may be incomplete and solve only part of the problem but at least the part you've written so far works.

In other words, do not attempt to write your program to perform all the necessary tests or produce completely correct output at first. Add code to perform only one processing step at a time and produce its output, and then add another until your program is complete.

For example, here is one way to begin developing the program one part at a time. Write the code for each of the following steps, and compile and test at each stage to make sure the correct results are printed for different inputs before going on to the next step listed.

First you could write code which reads the observation values. To be sure they are being read correctly, add statements which echo each one immediately after reading.
If your code so far works, write the output lines which correctly format the echo of the information for the first lines of output as described above.
When you have verified that these input and output statements work properly, you could determine which set of rules will be used for this set of observations based completely on the forecast rules given.
Then go through different cases - one for each forecast and make sure the output produced is correct for that situation.
Finish the remaining cases one at a time, and thoroughly test your program using a variety of input combinations.

4.2 Finding compilation errors

As before, if you get the error ``Invalid statement'' and the compiler identifies the very last line in your program, it usually means you have mismatched braces. Carefully match up all of your braces, and make sure that there is a closing brace to match every opening brace. This is much easier to do using a printout, and is far easier when your program is formatted neatly using proper indentation and placement of braces. Draw a line pairing up each set of matching braces until you can tell where one is missing.
If you get the error ``Invalid statement'' and the compiler points right to an else, the else is not placed so it's inside an if statement. Only one statement can appear as the subsidiary statement after an if, and only one statement can appear after an else. If you want more than one statement to appear in a place where one statement belongs, you can use braces to group them into a compound statement. You may have forgotten braces around the statements which were supposed to be executed if the condition in the if/else was true (the first group of subsidiary statements). Alternatively, it's possible you made a mistake and have more elses than ifs. You are much less likely to make this mistake when your code is properly formatted and indented, with each else lined up to clearly indicate which if statement it belongs to.

4.3 Program debugging

If your program doesn't produce the results you think it should, the debug printf statement is the best tool you can use. If, for instance, you're not sure why one branch of an if/else statement is being executed when you think the other should be, put a debug printf statement right before the whole if statement which prints the values of all the variables used in the condition. Maybe one of them doesn't have the value which you think it should have at that point. On the other hand, if you run your program and see that the variables all have correct values, then the condition itself is probably not expressed correctly. Or perhaps nothing prints in some case where you think something should. Try adding an else to every if statement which doesn't already have one, which prints a message indicating what must be true for that statement to be printed. Also in other cases, add as many printfs as you need to determine what is true about the data currently stored.

Make sure the debug printfs you add are descriptive in nature to tell you any information you may need to determine what your program is doing, such as what line in in the program is producing this output or what the values of all relevant variables are at that point. This is much more useful than printing something like ``I am here'' in your debug printfs. Also, make sure the debug printfs do not change what statements are controled by the if or the else.

Also for technical reasons not worth explaining, it is very important that every debug printf ends with the newline character '\n'. Although these debug printfs will make your output look incorrect, they will help you develop your program correctly.

Make sure that all debug printfs are removed before you submit your source code file for grading. After removing them, before submitting your source file, make sure that you have compiled, run and tested your project again to be sure you did not accidentally change it when you were removing those lines.

If you can't find the problem after trying to debug your program using these techniques, bring printouts of your program and any compiler errors or execution results to office hours. To help us find the mistake as quickly as possible, be prepared to demonstrate and explain how you have tested your program, and what results you got.

4.4 Program testing

It is very important to test your program against all different possibilities of input data, not just the values shown in the sample output section below. Doing this correctly involves thinking of what other input values are possible based on the project description, and what results the program should produce in those cases.

As an example, say you had to write a program which reads three integers into variables a, b, and c, and prints the name of the variable which had the largest value. Imagine that you wrote the following program:


#include <stdio.h>

main() {
  int a, b, c;
  scanf("%d%d%d", &a, &b, &c);

  if (a <= b) {

    printf("b");

    if (b <= c)
      printf("c");

  } else printf("a");

  printf("\n");
  return 0;
}

Try typing, compiling, and executing this program.

If you run the program and enter 2 6 4 it prints ``b'', which is correct.

If you run it and enter 6 4 2 it prints ``a'', which is correct.

You might assume the program works since you ran it twice with different input values, but it is not correct.

Try entering 4 2 6 and it prints ``a'', which is wrong.

Try entering 2 4 6 and it prints ``bc'', which is also wrong.

There are other possibilities of input values which cause incorrect results as well.

The conclusion is that it is always necessary to think of all the different possible combinations and possibilities of input values which might appear in a program's input, and test it so you are certain it works correctly in all cases, not just for one or two different inputs.

If you are curious, one correct program to perform this task is as follows. The program could also be written using the logical operators.


#include <stdio.h>

main() {
  int a, b, c;
  scanf("%d%d%d", &a, &b, &c);

  if (a <= b)

    if (b <= c)
      print("c");
    else print("b");

  else

    if (a <= c)
      print("c");
    else print("a");

  printf("\n");
  return 0;
}

4.5 Helpful hints

One development policy which is extremely important is to use proper indentation from the beginning. Many students type in their programs any way at all, with poor or no indentation, figuring once their project works correctly they will clean it up before submitting it. This is a very bad idea, because it is much harder to find certain errors in a program with poor indentation, and it's much easier to make these types of mistakes. You are much more likely to have problems such as mismatched braces, or misplacing an else, or misunderstanding which statements are subsidiary to which if statements if your code is improperly formatted or indented, or the braces are incorrectly placed. In the Q+A sections your textbook shows several popular styles of indentation. It doesn't matter which you use, as long as your code is clear and your indentation is consistent, subsidiary statements are all indented, and statements at the same level are all indented the same way. If you come to office hours for help with a program which has missing or very poor indentation, you will be asked to correct and reformat your program before we are able to help you further with it.

5. Academic integrity statement

Any evidence of unauthorized use of computer accounts or cooperation on projects will be submitted to the Student Honor Council, which could result in an XF for the course, suspension, or expulsion from the University. Projects are to be written INDIVIDUALLY. For academic honesty purposes, projects are to be considered comparable to a take-home exam. Any cooperation or exchange of ideas which would be prohibited on an exam is also prohibited on a project assignment, and WILL BE REPORTED to the Honor Council.

VIOLATIONS OF ACADEMIC HONESTY INCLUDE:

failing to do all or any of the work on a project by yourself, other than assistance from the instructional staff.

using any ideas or any part of another student's project, or copying any other individual's work in any way.

giving any parts or ideas from your project, including test data, to another student.

having programs on an open account or on a PC that other students can access.

transferring any part of a project to or from another student or individual by any means, electronic or otherwise.

IT IS THE RESPONSIBILITY, UNDER THE UNIVERSITY HONOR POLICY, OF ANY STUDENT WHO LEARNS OF AN INCIDENT OF ACADEMIC DISHONESTY TO REPORT IT TO THEIR INSTRUCTOR.

6. Submitting your project

Your project must be electronically submitted by the date above, before 11:00pm, to avoid losing credit as indicated on the syllabus. No projects more than two days late will be accepted for credit without prior permission or a valid medical excuse, as described on your syllabus. Only the project which you electronically submit, according to the procedures provided, can be graded; it is your responsibility to test your program and verify that it works properly before submitting. Lost passwords or other system problems do not constitute valid justifications for late projects, so do not put off working on your program or wait to submit it at the last minute!

Turn in your assignment using the ``submit'' program as before, except using ``2'' for the project number. You are to submit only the .c file containing your source code, not the executable version of your program! If your program is in a file named ``forecast.c'', submit would be run as shown.

% submit 2 forecast.c

Before you submit your project, you must exactly follow the specific submission checklist in the ``Testing projects before submitting'' handout separately posted by your instructor!

7. Sample output

Assuming the name of the executable version of the program is ``forecast.x'', here are three executions for three different sets of input values. Note that the input file is shown separately before each output set, and nothing is typed by the user as the program is run.

Be sure to test your program against a variety of inputs, so you are sure it works in all circumstances!

% cat input1 12/1/00 7:00 1022 4 12/1/00 5:00 1016 2 % forecast.x < input1 Current observation 12/01/2000 07:00 Barometer: 1022 millibars, rising rapidly (3.00 mb/hr) Wind direction: W ****FORECAST**** Fair; rain within 48 hours. We are happy to provide this forecast. % cat input2 12/2/00 2:00 1020 4 12/1/00 23:00 1018 2 % forecast.x < input2 Current observation 12/02/2000 02:00 Barometer: 1020 millibars, steady (0.67 mb/hr) Wind direction: W ****FORECAST**** Fair with no significant temperature change for 1 to 2 days. We are happy to provide this forecast. % cat input3 12/1/00 7:00 1023 2 12/1/00 5:00 1027 2 % forecast.x < input3 Current observation 12/01/2000 07:00 Barometer: 1023 millibars, falling rapidly (-2.00 mb/hr) Wind direction: S ****FORECAST**** Wind increasing, with rain within 12 to 24 hours. We are happy to provide this forecast.

Steve Scolnik
2001-09-26

Web Accessibility