Due date: 8:00 A.M. Monday, October 6th
You are running a ``Couples Counseling'' service. Troubled couples come to
you for therapy that they hope will save their relationship!
This program will prompt the user to enter today's date, the birth date of
the user and the birthdate of the user's partner. It will then determine
how much therapy (if any) the couple will need to get better. (It's
amazing how this can be done by just knowing the birthdays of the people
involved!)
You might want to begin by looking at the ``Sample Run'' section at the
end of this document.
The program begins by printing a cheerful message:
Welcome to the Couples Clinic. We are here to help.
Next the program prints a blank line, then prompts the user for
today's date, the user's
birthdate, and the birthdate of the user's partner. Note that each date
is entered as three individual integers. Here is an example:
Enter today's date (mm dd yy): 9 27 03
Enter your birthday (mm dd yy): 8 21 83
Enter your partner's birthday (mm dd yy): 5 3 79
Here, the user has specified that today is September 27th, 2003. His/her
birthday is August 21st 1983, and his/her partner's birthday is May 3rd,
1979.
The first thing the program will do is find out what ``generation'' the
couple is part of. People born before 1938 are considered ``senior
citizens''. People born from 1938 to 1967 are considered ``baby boomers'',
and people born 1968 or after are considered ``generation X''.
If it turns out that the two individuals are not from the same generation,
then your program will determine that they are fundamentally incompatible,
and will print a blank line, followed by the message:
You are from two different generations! Just break up.
In this case, the program should then terminate without printing any further
messages.
Assuming that both people are part of the same generation, the program will
print a blank line, followed by
one of the following messages, depending on the generation:
You're Senior Citizens! I am certain that I can help you folks.
You're Baby Boomers! Chill out, I can help you, man.
You're Gen-Xers! Dude, I can like TOTALLY help you.
If both partners are in the same generation, then an extensive
calculation will be performed that will determine
how compatible the couple actually is.
We will use the following terms to discuss how compatible a couple is:
- Good Karma. Couples who are born in adjacent months have
good karma. (The year in which they were born is not important.) For
example, if one partner was born March 1955, and the other was born
April 1960, they have ``good karma'' because March and April are
consecutive. (We will consider December and January as consecutive also.)
Note that couples born in the exact same month do NOT have good karma.
- Bad Karma. To determine whether or not a couple has ``bad
karma'', begin by finding the sum of the dates of their births. Here we
are only concerned with the day, not with the month or year. For example,
if one person's birthday is September 14th, 1982 and the other's is
February 27th, 1979, we would add 14 + 27 and get a sum of 41. If this
sum is divisible by 7, 13, or 3, then the couple has ``bad karma''.
- Bad Age Separation. If the years in which the partners were
born are more than 6 years apart, this is considered a ``bad age
separation''. Note that the month and day of birth is irrelevant, just
compare the years. For example, 1960 and 1967 are more than 6 years apart,
even if one partner was born at the end of 1960 and the other was born at
the beginning of 1967.
- Good Age Separation. (First read the paragraph above). If
the difference in years (computed as above) is 2 or less,
then the couple has ``good age separation''.
- Good Synchronization. First add together the values for
month, day and year for each partner. If these two sums both end in the same
digit, that is ``good synchronization''. For example, if the birthdays
are February 9th, 1967 and April 15th, 1969, the sums both end with the
digit '8', so these people have ``good synchronization''.
- Bad Synchronization. Take a look at the very last digit in the
``day'' of each person's birthday. We are ignoring the month and year. If
these digits match, then the couple has ``bad synchronization''. In other words, if one person
is born on the 13th and the other on the 23rd, then they
have ``bad synchronization''.
Note that the categories above are never mutually exclusive. For example, it
is possible for a couple to have both ``good synchronization'' and also ``bad
synchronization''.
We will calculate the compatibiltiy of the couple as follows. The couple
starts off with a base compatibility rating of 0. This is adjusted by
adding or subtracting amounts as described below:
- Good Karma.
- +6 for Generation X
- +4 for Baby Boomers
- No effect for Senior Citizens
- Bad Karma.
- Good Age Separation
- +4 for Generation X
- +2 for Baby Boomers
- +1 for Senior Citizens
- Bad Age Separation
- -12 for Generation X
- -6 for Baby Boomers
- -2 for Senior Citizens
- Good Synchronization
- Bad Synchronization
Adjust the couples compatibility index by adding or subtracting any of the
items on the list above that fits. For example, a couple who are
Baby Boomers with Good Age Separation, but with Bad Synchronization would
get a compatibility rating of -3.
There must be a blank line between the ``I can help you'' greeting
and the rest of the output.
There must be a blank
line between each subsequent line of output.
If the couple's compatibility index is greater than or equal to zero,
then print the following message:
Your compatibility index is %d. You don't need my help!
(where %d is the compatibility index.)
In this case, the program should terminate without further output.
On the other hand, if the couple's compatibility rating is less than zero,
then it dictates how many days of therapy they will need. For example,
if the rating is -6, then the couple will need 6 days of therapy.
For couples needing therapy, your program will print a line that says:
You will need %d days of therapy.
(where %d is the number of days of therapy required.)
You must then calculate how long the couple will remain under your care,
assuming that the therapy will start on today's date (which was entered by
the user of the program.) For example, if the user entered the date
March 6th, 2003, and the couple will require 8 days of therapy, then their
therapy will end on March 14th, 2003.
You will then print a line that says:
You will remain under my care until mm/dd/yy.
where ``mm'', ``dd'', and ``yy'' represent the month, day and year of the
end of therapy. (In the example from the paragraph above, you would print
the date as 03/14/03.
Note that we insist on printing exactly 2 digits for each of the three
fields.
You will need to know how many days are in each month in order to calculate
the end of therapy date.
For example, if you begin therapy on September 27th, and you need 6 days
of therapy, you won't finish until October 3rd. This relies on knowing that
September has 30 days. The following chart will help:
You may ignore leap years or any other periodic calendar adjustments
in the date calculations.
| Days in each Month |
| January |
31 |
| February |
28 |
| March |
31 |
| April |
30 |
| May |
31 |
| June |
30 |
| July |
31 |
| August |
31 |
| September |
30 |
| October |
31 |
| November |
30 |
| December |
31 |
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 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. 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
- all lines must be less than 81 characters long
- use of symbolic constants for ALL constant values.
- avoiding disallowed C language features as discussed above
- you must avoid writing duplicative code; you will be penalized
for poor program design
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:
- Compile your program - let's suppose the executable is called
a.out
- 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
- 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.
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.
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.
- 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.
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 controlled 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.
It is very important to test your program against all different
possibilities of input data, not just those provided by us. 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)
printf("c");
else printf("b");
else
if (a <= c)
printf("c");
else printf("a");
printf("\n");
return 0;
}
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.
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.
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.
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 ``p2.c'', submit would be run as
shown.
% submit 2 p2.c
Welcome to the Couples Clinic. We are here to help.
Enter today's date (mm dd yy): 9 26 03
Enter your birthday (mm dd yy): 11 3 78
Enter your partner's birthday (mm dd yy): 5 6 75
You're Gen-Xers! Dude, I can like TOTALLY help you.
You'll need 5 days of therapy.
You will remain under my care until 10/01/03
This document was generated using the
LaTeX2HTML translator Version 2K.1beta (1.61)
Copyright © 1993, 1994, 1995, 1996,
Nikos Drakos,
Computer Based Learning Unit, University of Leeds.
Copyright © 1997, 1998, 1999,
Ross Moore,
Mathematics Department, Macquarie University, Sydney.
The command line arguments were:
latex2html -show_section_numbers -split 0 -no_navigation -no_footnode p2
The translation was initiated by Fawzi Emad on 2003-09-26
Fawzi Emad
2003-09-26
Web Accessibility