CMSC 106

Project #1 - Fruit Drop

Fall 2002

Due date: 11:00 pm on Friday, September $27^{th}$ 2002.

Purpose

In this project you are to write a C program which will declare variables, read values into and write the values stored in those variables, and perform various calculations and assignments using them. You will also have the opportunity to become familiar with the system facilities to be used for developing projects in this course: several basic UNIX commands, the text editor, the C compiler, and the ``submit'' program used for electronic project submissions.

Project description

You will write a program that will simulate dropping tomatoes and watermelons off a cliff. First the program will ask the user to specify the weight of a tomato, and the time it will take for the tomato to hit the ground. Then the program will ask the user for the weight of a watermelon, and the velocity at which it will hit the ground. The program will use these input values to calculate various facts about these falling objects.

Below is an example of a typical run of the program. When your program runs it must look exactly like this. Of course the four input values that appear in boldface type are provided by the user of the program, so they will vary, as will the resulting output values. Here is the example:

LET'S DROP SOME STUFF OFF A CLIFF.

Experiment #1: THE TOMATO
Enter the weight of the tomato (ounces): 4.34
Enter the time required to hit the ground (seconds): 2.7

Experiment #2: THE WATERMELON
Enter the weight of the melon (lbs): 12.291
Enter the velocity of the melon when it hits the
ground (miles per hour): 55.0

AND NOW THE RESULTS!

The tomato was dropped from a height of 117 feet 4 inches.
It hit the ground travelling at 59.25 miles per hour.
The kinetic energy at impact was 43.16 Joules.

The watermelon was dropped from a height of approximately
101 feet (that's about 31 meters).
Fragments struck bystanders as far away as 29.30 feet.

Formulas

Variable definitions:

$m$ is the mass (weight) of the object (kilograms)

$v$ is the velocity of the fruit at the moment when it hits the ground (meters/second)

$t$ is the time (seconds) it takes to fall all the way to the ground

$h$ is the height at which the fruit was released (meters)

$E$ is the Kinetic Energy at the time of impact (Joules)

$R$ is the ``Blast Radius''. This specifies how far the fragments might fly (meters).

The following formulas describe the simple physical laws that we will assume dictate the behavior of our falling objects. These formulas correspond to the Newtonian model, assuming there is no air resistance, and that the mass of the falling object is negligible compared to the mass of the Earth. Note that you may have to rearrange a particular formula to be able to use it for what you need.

$v = 9.81t$

$h = 4.905t^{2}$

$E = \frac{mv^2}{2}$

$R = 0.0053E$ [Okay, we made this one up, don't believe it.]

Conversion Factors

You must use the following conversion factors when you need to convert quantities from one unit to another:

1 mile = 5280 feet

1 foot = 12 inches

1 hour = 3600 seconds

1 meter = 3.2808 feet

1 ounce = 28.3495 grams

1 lb = 16 ounces

1 Kilogram = 1000 grams

Even if you know other conversion values (even if more accurate), you must use these values for all conversions. These conversion factors must be stored in your program as symbolic constants, using #define.

Error Checking (or the lack thereof)

Your program may assume, without checking, that the user will enter the four input values in an appropriate way. All four values are intended to be stored as positive floating point numbers. You may assume that the values entered will be reasonable, and your program does not have to do any error checking of any kind with respect to these values.

Formatting and Rounding

In this project, you should use float variables (or expressions) for quantities which are described as real numbers, and int variables for whole number quantities. Chapters 2-4 of your text don't discuss how expressions which contain both int and float values are evaluated (this is covered in detail in a later chapter). In order to avoid any problems with your calculations, you should realize now that expressions with both int and float values will have a float value when computed.

When writing the expressions for the conversions, be aware that doing the statements in a different order can cause you to get a different answer. For example (52/5200) * 100.0 = 0.0 but (52*100.0)/5200 = 1.0. This is because the 52/5200 is calculated into an integer storage place since both operands are integers. The answer is actually 0.01, but because it is forced into and integer space, only the 0 is stored. Then when it is multiplied by 100.0, the answer is 0.0 because any float times 0 is 0.0. When the second expression is evaluated, the 52 * 100.0 makes it 5200.0 (a floating point number), and then when the division happens, the answer is 1 because there was no truncation. If you have two integers and you want to make sure the result is stored in a float, one easy way is to multiply one of the operands by 1.0 before the other operation is done.

Do not round off your answers until you are ready to display them. If you do several successive computations, rounding each time, your answers will not be accurate.

Most of the values that your program will display must appear as floating point values with two digits after the decimal place. (See the sample run, above.) However, there are a few exceptions:

• When displaying the ``feet and inches'' for the height of the tomato, you must round to the nearest inch.
• When displaying the height for the watermelon, you must take your accurate floating point value for height and round it to the nearest foot, and to the nearest meter.

Project requirements

All your C programs in this course should be written in ANSI C, 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 4 of your textbook, plus those presented in lecture while these chapters were covered. Note that as a result conditional statements of any type may not be used. 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. 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

• writing clear and readable code

• use of meaningful descriptive variable names

• use of symbolic constants where appropriate

• avoiding disallowed C language features as discussed above

Primary Input and Output

We have provided two files (primary_input and primary_output) to help you test your program. If your program is run using the file primary_input as the data source, then the output should look exactly like the file primary_output. You can use UNIX redirection and the diff command to check your program with this sample data. Here's how:

1. Compile your program - let's suppose the executable is called a.out

2. Run your program using primary_input as the data source, and another file for the output. We'll suppose the other file is called myoutput:

   % a.out < primary_input > myoutput

3. Check to see if your output file matches the primary_output file:

   % diff -bwi myoutput primary_output

If your output is correct, the diff command should generate no output of any kind. If your output is different from the primary_output file, the diff command will show you what lines are different.

Important: We will be testing your program with many different data sets, not just the primary_input mentioned above. You will lose substantial credit for each test case that your program does not handle correctly. For this reason, it is very important that you test your program with a wide variety of input data.

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.

A crucial part of the material to be learned in this course is how to properly develop programs and find the inevitable errors you will make while writing them. This section addresses how to do that. It is not up to the instructional staff to find every error in your program; you need to learn how to find and fix most of them for yourself. If you have tried the techniques below and have still not been able to find or correct a problem, bring a printout of your program (plus printouts of any compiler errors or execution results) to our office hours and we will be able to help you.

Possible development steps

Many people like to write their whole program, or at least have a good outline and idea of what it will look like, before sitting down to type any of it in. That's fine, but it is absolutely essential that you never type in more than a short part of your program without stopping to test what you have so far. You should stop and compile your program, run it on sample input, and verify that it works correctly so far before going on to enter the rest of the program! Of course, as each intermediate stage the part of the program you have entered will obviously not solve the whole problem, and it must at least be a complete and valid C program, but you will find that testing your project at each stage of development will insure you can find and fix any errors more quickly and easily.

For instance, even with a relatively short program like this one you might enter or implement it in steps as follows:

1. First type in just the part of your program which prints the first line, and reads the input values typed in by the user. You will need declarations of variables into which the values are to be read. Add debug printf statements to print the values which were read, to make sure these values were read and stored correctly. If not, correct your program before going on!

2. Next add symbolic constants for all conversion factors, and figure out the formulas necessary for the first computation (the height of the tomato). Calculate the appropriate values, and produce just this first line of output. Compile your program and make sure it produces correct results for the part you have entered so far before going on.

3. Then add the code each of the other lines of output, one at a time. Compile and test your program at each step to be sure that things are working correctly before moving to the next step.

4. Lastly, make sure all of the output exactly matches what is specified in the project description. (Placement of words, punctuation, and line breaks should all be double checked.) Test your program using the primary input case, described above.

In fact, you may want to break each of these steps up into smaller steps- to add statements to print intermediate values part of the way through the computations.

Many programs can be developed with equal ease in different orders. The specific steps followed are not important; what is crucial is that you stop and compile and test your program after each one.

Finding compilation errors

1. Usually the compiler tells you exactly which line in your program is incorrect. If you can't figure out what's wrong by looking at that line, you'll just have to use your textbook or class notes and compare a correct example of that type of statement with what you wrote.

2. Sometimes the compiler can't always recognize a syntax error immediately (such as when you've forgotten the semicolon which must terminate every C statement), and doesn't notice it until the next line or statement. If the statement the compiler identifies as wrong looks correct to you, try examining the one before it for any errors.

3. If you see the error ``Invalid statement'' and the compiler identifies the very last line in your program, it usually means you have mismatched braces ({ }). Make sure that there is a closing brace to match the main function's opening brace. Indenting statements between braces in a readable manner will assist in this task.

4. Here are a couple of unusual compilation errors produced by the cc compiler on the OIT UNIX class cluster and what they mean:

   ld: Unresolved print

   (or scan, or Printf) This means you have misspelled the name of one of the standard library functions (printf as print or Print, scanf as scan, etc.). Every program component must be spelled exactly, and even one incorrect character will cause your program to fail to compile. Check every call to these library functions carefully.

   An unexpected newline character is present in a string literal

   You probably forgot either the opening or closing double-quote mark in one of your printf or scanf argument strings.

   Object file format error... bad file magic number

   The cc C compiler requires that a source file's name end in ``.c''. That's a lowercase ``c'', as in a filename like ``proj1.c''. If your program's filename isn't in that format you must rename it.

Program debugging

It is inevitable that many, if not most or all, of your programs will fail to work correctly as initially written. A few simple strategies can help:

1. Carefully trace your program through on paper assuming certain input values, and keep track of the current values of all of the variables.

2. You may need to add debug printf statements to your program to print out the values of variables and calculations. Essentially, this lets the computer trace your program for you. If the printf statements show that your variables or expressions don't contain or produce the values you think they do then that's a clue to what's wrong. Using debug printf statements you can narrow the problem down and determine which variables or expressions don't have the proper values, and then look at those more closely.

3. If, when you run your program, you get the error ``Floating exception (core dumped)'', this means your program has an unrecoverable execution error. This most likely means you are either trying to calculate some expression containing a division and the denominator's current value is zero, or you are trying to perform some calculation with a float variable which has never been given a initial value and contains a garbage value. To check for the first case, add debug printf statements before every division printing the value of the denominator. To check for the second one, check carefully that all your float variables have initial values or that values are assigned to them or read into them before they are used in calculations.

4. Another fatal execution error is ``Segmentation fault (core dumped)''. In a program like this one, this message usually is caused by a few mistakes related to the differences between printf and scanf. See your lecture notes where this was discussed, or look at your textbook on pages 39-40.

5. If your program just hangs and doesn't do anything after you type values to be read into certain variables and you've pressed the enter key, you are likely to be making another error in confusing printf with scanf. See your class notes, or carefully reread pages 39-40.

6. Note: If you get either of these ``core dumped'' errors. You most likely now have a file named ``core'' in the current directory. Core is the central part of memory, and to dump the core means that it gave you a file containing what core looked like at the time the program died. This is most likely a very large file and most likely something you don't want to read so it is good to delete it to get it out of the way.

7. If, after you have tried these techniques you still can't figure out why your program doesn't work, bring printouts of your source code and any compiler errors or output produced to our office hours, and we can teach you how to track the problem down.

Further helpful hints

Readable code is important in the real world because most of the programmer's time is spent rewriting or modifying code that already exists - not writing code from scratch. To make your code readable, be sure to use descriptive variable names (English words or their abbreviations), indenting (so that you can tell what statements are dependant on others), vertical whitespace (blank lines between sections) and comments for the person reading the code. Even though in this class you will not be rewriting someone else's code - anyone of the instructional staff who reads your code will be able to do so much quicker and the grader will be much more likely to be able to follow your code if you make it readable right from the start.

Remember that the vertical spacing (what appears on each line) is up to you as you type. Emacs does not do a word wrap - so if there is a very long line, you should press the enter key to wrap it to the correct position on the next line to make the code as readable as possible.

Keep one or two backup copies of your program saved under different filenames or in different subdirectories of your account. Before making any major changes to your program, copy it to a new backup file with a different name. This will save you a lot of time if you accidentally delete your file, or if it turns out that your changes were incorrect and you want to quickly revert to the previous version without having to undo all of your modifications by hand.

Always start all your projects as soon as they are assigned! If you end up having a problem which you can't solve on your own you will have plenty of time to come to office hours for help. If you wait until right before a project is due and you run across such a problem it's too late to get help without having to submit your project late and lose credit.

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:

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

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

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

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

5. 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.

Submitting your project

Your project must be electronically submitted by the date above, before 11:00 pm, 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 provided by your instructor. You are to submit only the .c file containing your source code, not the executable version of your program!

If your source code was in a file named ``p1.c'', submit would be run to turn it in as shown:

% submit  1  p1.c

In order to execute either submit command above you must have previously run the ``setup'' command in your instructor's posting account, as described in discussion section and mentioned again below. If you do not see a message saying your submission was successful then your project was not turned in. Try again, or come to office hours for assistance.

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

Class announcements- reminder

Be sure to read your instructor's class announcements every time you log in, or frequently on the class webpage, for important information which may be present. You are responsible for the content of these announcements. To be certain to never miss this information, and so you can submit your projects, you must execute the command source ~<instacctID>/setup which will cause these announcements to be displayed whenever you log in (where <instracctID> must be replaced by the name of your instructor's class posting account). This only needs to be done once for the semester, and the announcements will be shown every time you log on afterwards.

Web Accessibility