Lab #5 Assignment
CSE 1320-002
Spring 2012
Lab 5 updated, May 2, 2012
Design Document Due Date: May 1, 2012 at noon (12pm)
Lab Due Date: May 10, 2012 at noon (12pm) Extra credit for early submission – See website
(see instructions on website for how to turn this in - Òlab submission infoÓ)
Grade value: 12% out of 100% for all grades
Objective: The goal for this lab is to provide an opportunity for practice of C program development and the C programming topics covered in Foster and Foster as covered in class. It is assumed that the student is familiar with the programming concepts but not the C syntax. This lab continues Dr. TÕs approach to lab assignments and reinforces and refreshes previously learned material about C and programming.
Every lab assignment allows students to practice program development, debugging, and testing. All of these skills are crucial to success in Dr. TÕs class. The format of this assignment is similar to the assignments that will be required for the rest of the semester so a student who is unsure of their skills can use this assignment to refresh them and to ask the instructor or TA about any concepts they are unsure of.
Topics:
Linked lists
Command line parameters
Multiple program files
Testing and test plans
Pointers
Structs
Recursion
Algorithms
Searching
Sorting
File input
One-dimensional Array
Multi-dimensional Arrays
Strings
Control structures
Functions
Arithmetic and relational operators
Input and output,
Passing parameters
Data types
Global constants
Pre-processor directives
Program design
Modular programming structure
Error checking
Programming style
Compiling code,
Executing code,
Debugging and testing.
Plan: Dr. T gives an overall problem that students work on all semester. Each lab assignment implements specific concepts. Succeeding assignments will modify and extend previous assignments.
Overview: For the rest of the semester you will be trying to determine a price to charge for an event and other data based on the venue size (number of seats), the fixed event costs, the amount of tickets you expect to sell, some profit margin, and other criteria. You will also make various other calculations as required. You are going to get information from the user and store that information in a certain way. WeÕll call this the data-entry phase of the program. Once all the input data is entered, your program will allow another user to perform various tasks on the data by choosing tasks from a menu. WeÕll call this the menu-driven phase of the program. The user can continue to choose tasks from the menu as long as desired and one of the menu choices must be to end the program. The program ends correctly when the user chooses that option.
You are also required to design your program in advance before you begin writing code. You will document your design and turn in the design document typically a week before the lab assignment is due. The goal of the design document is to assist you in developing the actual program.
This assignment has an overview section, a task description section, an implementation requirements section, a grading scale, and a deductions section. If there is additional info needed it will be in a miscellaneous section at the end of this lab assignment. Read ALL of the assignment before you start trying to develop the program.
Be sure to check the DEDUCTIONS section at the end of this assignment to avoid penalties. You may NOT use global variables, the exit command, goto, break (except in a switch), continue, passing by reference (except arrays) (removed mention of linked list as a deduction). You should do input and output using printf and scanf (you are allowed to use getchar and putchar if desired.) You must use getline for string input. You should not need to use any library functions beyond those mentioned in the book and in class.
Assumptions for the lab #5:
1) Strings will have a maximum length of 60 chars. There are no restrictions on the contents of the string. ÒBass HallÓ is a valid string input for this lab. Use constants to define the max value.
2) The maximum number of different kinds of seating in a venue for Lab #5 is 5. Use constants to define the max value.
3a) There is no maximum number of venues for Lab #5 but there is a minimum of 8 venues.
3b) There is no maximum number of events for Lab #5 a but there is a minimum of 6 events.
4) For date checking in Lab #5, you may NOT make the simplifying assumption that all months have 30 days. You must check dates accurately.
5) In Lab #5 you should use the built-in time functions to get the current date as the date to check against for a ÒfutureÓ date.
Problem: The data in your database will be venues for events, event information, profit goals, and more. As part of this assignment you will have to find real data about some venues and events to use as test data for your program.
When the user runs your program, they must first enter data. The data they entering will be the venue and event information that you have researched to use as your test data. After getting all the input data from the user (and storing it in a sorted singly linked list), you will allow the user to do the following: (Many of these functions must be revised with new data structures for Lab #5.)
1) Using the data in the linked list,
A) Print all of part of the data in a table
B) Calculate
i. Best venue for an event
ii. Cost to set for ticket prices
C) List all the venues that meet certain criteria
i. Less than given usage cost per hour
ii. Larger than a given size
iii. In a given city as determined by the venue code
D) Search for a venue by
i. Type of venue
ii. Type of seating available
E) Search for an event by
i. Size of the event
ii. Type of event
iii. Cost of ticket price
F) Sort the venues by
i. Venue code
ii. Total seating
G) Sort the events by
i. Date
ii. Length of event
2) Update the data in the linked lists – this will take the user to a submenu for doing updates, additions and deletions
3) End the program
Data Description: For lab #5, you will be storing the input data in sorted singly linked list of structs. You will use the struct data types from Lab #4 – one for an event, one for a venue, and one for information about a single type of seating – but you will add ÒlinksÓ, i.e. pointers to structs, inside each struct. The seating struct will be used inside the venue struct as was demonstrated in class.
The data elements and descriptions are given below. Following this first list, the data elements are described by type and by which struct they will belong to.
1) Venue code - a four digit integer where the digits represent a venue location using the guidelines given at the end of the assignment.
2) Venue name – a string less than 60 characters long that gives the venue name. In lab #5 we are using strings for the name without simplification which means that the names can have spaces, e.g. College Park Center is a valid name.
3) Venue type – a letter representing the type of venue. Choices are:
B Basketball arena
T Theater
A Auditorium
F Football stadium
C Concert hall
L Large room (seats > 150)
S Small room (seats <= 150)
O Outdoor performance area
M other miscellaneous type of venue
4) Venue kinds of seating (festival, selected, special, box, VIP) – an integer of value 1- 5 followed by that many letters of either F, S, P, B, or V. Must offer either festival or selected seating at a minimum. The number represents how many types of seating are available and the letter code(s) indicate which kinds of seating they are. Festival seating is seats that are not specifically assigned, selected means the seats are assigned in some way, box seats are unique seating areas that are partially enclosed in some way, VIP seats are any seats that are used for VIP guests, and special is any other type of seating which could include lousy seats like in the high balcony, seats in the stage wings, seats in the choir loft, etc.
Ex: 3 F P B
5) Venue amount of seating of each kind – same number of values as previous info giving a list of number representing seats of the available types. Ex: for example above, 400 100 24
6) Venue cost per hour – a floating point money amount that is the amount that the venue charges per hour. Ex: 500.00 to represent $500.00 per hour
7) Event date – Event date as day, month, and year - three separate numbers
8) Event type – a letter representing the type of event. Choices are:
S Sports
A Arts and entertainment
C Community
P Public welfare
G Group participation
O Other
9) Event setting (intimate, average, large, mass) – they are ranges of performance preferences for audience size. This will help select among venues if needed. This is a letter representing one of the four setting sizes: I intimate (less than 300 people), A average (300 – 999 people), L large (1000 – 3999), M mass (4000+)
10) Fixed event cost – A floating point money amount that is the fixed amount charged for the performance/event
11) Event length in hours – An integer (must be > 0)
12) Desired profit percentage for event – A floating point number representing how much profit margin is desired. 33% is 0.33 (can be 0)
13) Desired profit fixed amount for event – A floating point number (can be 0) that indicates a specific dollar amount of profit desired.
14) Percentage of kinds of seating in the venue expected to sell – Ticket types within any one kind of seating are discounted and regular. The values for this input are two floating point numbers representing how much of each kind of seating you expect to sell. Ex: 1.00 0.75 would indicate 100% of discounted seating is expected to be sold and 75% of regular seating.
15) Chosen venue for event – this will be the venue code of the venue where the event will be held.
16) Recommended ticket prices – (up to 10 different values) – this value will be calculated and should be stored as floating point numbers. The possible combinations are discounted Festival seating, regular Festival, disc. Selected, reg. Selected, disc. sPecial, reg. sPecial, disc. Box, re. Box, disc. VIP, and/or reg. VIP.
17) Count of venue entered – integer that is the number of venues the user entered data for. Max is 15 and min is 8. This number is determined by user input.
18) Count of events entered – integer that is the number of events the user entered data for. Max is 20 and min is 6. This number is determined by user input.
19) Percentage of seating that will discounted – floating point value. In previous labs, this was a fixed amount of 15%. Now you will allow the user to input this amount.
20) Percentage of seating that will be regular price – floating point value. This must be calculated as 100% - discount percentage.
21) Event name
The format for each piece of data is listed below.
You will create three struct types for the input data to be stored in. The first struct type will be the event struct which will hold all the data items for the event. The second struct type will hold all the data items for one venue including an array for the seating data. The seating data will be another struct type and you will have an array of size 5 of the struct seating type as one member of the struct venue type. Declare the struct types globally and then declare the pointers for the linked list inside main. You will have a linked list of elements of type struct venue to store any number of venues. You will also have a linked list of elements of type struct event to store any number of events. To store your data for all the different venues (or events), you will allocate structs one at a time, fill them with data, then link them into the sorted linked list of structs.
As an example, letÕs say the user is going to enter two venues and one event. The first venue will be UT Arlington College Park Center (code 101 or 0101) and the second venue will be Bass Hall (code 221 or 0221). The event will be a concert. For each venue you will be asking the user for all the data about the venue and then storing this data into a newly allocated address in a struct venue pointer. The concert data will be stored in the struct event pointer addresses. Each member of the struct will indicate a different piece of data about the event or venue. The different venues, in this case the UTA CPC and Bass Hall, will be stored in the first and second structs that are created. These structs should be linked together in order by venue code as the data is being read in. To store data in the struct venue linked list, you allocate a new struct, assign the data to that struct, then determine where that struct should be linked into the existing list and add it to the linked list in order. As you read in the venues and events, you will NOT be numbering them.
For Lab #5 you will have minimum amounts of events and venues.
Make sure to declare all your constants (such as VENUEMIN or max string length) before you try to use.
Detailed descriptions of each data value. The data values below must be stored as described. You may also store additional values into these structs if desired. In the descriptions below count represents the either the venue count or the event count depending on which kind of data is being entered:
Pointers for venue and event lists: For venues, struct venue *newvenue, *currvenue, *headvenue, *folvenue; For struct event *newevent, *currevent, *headevent, *folevent; Initialize all external linked list pointers to NULL.
Venue data: Other than the count of venues, all the other data should be defined as members of the struct
Venue code - a four digit integer where the digits represent a venue location using the guidelines given at the end of the assignment. You will have to validate the digits of any code entered by the user. For the first venue, the venue code would be read in and error checked. If the value is valid, i.e. it passes error checking, then it is stored in the integer vcode member of the current venue struct in the list, i.e. newvenue->vcode where newvenue represents the address of the newly allocated struct whose values are being entered.
Venue name – a string less than 40 characters long that gives the venue name. The string will be read in with a getline command into a temporary string. The length of the string should be checked using the strlen command. If the string is less that 40 chars in length then it should be copied to newvenue->venname.
Venue type – a single character representing the kind of venue. It must match one of the valid venue type codes. If it is valid, it should be stored in newvenue->vtype.
How many kinds of venue seating – an integer of value 1 - 5. If it is valid, it should be stored in newvenue->vkindsstg.
Venue cost per hour – a floating point money amount that is the amount that the venue charges per hour. This value is stored in the newvenue struct at the vcost member for this venue, i.e.
Venue seating info – an array of type struct seating with 5 values. The array members must include either F or S at minimum to be valid. The number of array members with letters stored is determined by the How many value just described. The venseating array can hold 5 seating structs. The seating struct is described below.
Next venue – a pointer to another struct venue, i.e. newvenue->next
Seating data: The seating data struct will contain
Venue kind of seating – One letter of either F, S, P, B, or V. The letter that is read is stored in the venkind member of the seating struct in the venue list, i.e.
newvenue->venseating[k].venkind where k is a counter from 0 to newvenue->howmanykindsofseating -1. The letter should be error checked to make sure it is valid and to make sure that the same letter is not already stored in the array.
Venue amount of seating of each kind – a number representing seats of the current type. The value that is read is stored in newvenue->venseating[k].venamount .
Percentage of seating that will discounted – floating point value representing the portion of the seats of the current kind and amount will be sold at a discount. In previous labs, this was a fixed amount of 15%. Now you will allow the user to input this amount. The amount should be between 0.0 and 1.0 where .5 would represent 50%, .15 would be 15% and 1.0 is 100%. Error check the amount and store it in the discperc member of the seating struct, i.e. newvenue->venseating[k].discperc .
Percentage of seating that will be regular price – floating point value. This must be calculated as 100% - discount percentage and stored at venues[count].venseating[k].regperc .
Percentage of kind of discount seating expected to sell – floating point value representing how much discounted seating you expect to sell within the current kind of seating for a venue. Ex. For kind of seating of P, then there will be a percentage value ex. 0.9 which would represent 90% of discounted seats. This data is stored in the venseating array. Ex. newvenue->venseating[k].discoccupied
Percentage of kind of regular seating expected to sell – floating point value representing how much regular seating you expect to sell within the current kind of seating for a venue. Ex. For kind of seating of P, then there will be a percentage value ex. 0.75 which would represent 75% of regular seats. This data is stored in the venseating array. Ex. newvenue->venseating[k].regoccupied
Regular recommended ticket price – floating point value representing how much you will sell regular seating for within the current kind of seating for a venue. This value will be calculated and should be stored as a floating point numbers This data is stored in the venseating array. Ex. the regular price would be stored in newvenue->venseating[k].regprice .
Discoun recommended ticket price – floating point value representing how much you will sell discount seating for within the current kind of seating for a venue. This value will be calculated and should be stored as a floating point numbers This data is stored in the venseating array. Ex. the regular price would be stored in newvenue->venseating[k].discprice .
Event data:
Event date – Three integers representing the event date as day, month, and year - three separate numbers. These values are stored in newevent->evday and then in newevent->evmo and newevent->evyear. The dates should be error checked. You must check that the date is in the future compared to the current date.
Event type – a letter representing the type of event. It must match one of the valid event type codes. If it is valid, it should be stored in the list newevent->etype.
Event setting – a letter representing one of the four setting sizes. It must match one of the valid event setting codes. If it is valid, it should be stored in the list newevent->esetting.
Event length in hours – An integer (must be > 0). This value is stored in newevent->evlen.
Fixed event cost – a floating point amount (must be >= 0). This value is stored in newevent->ecost.
Desired profit percentage – a floating point number between 0 and 1 inclusive. This limits the profit to 100% of the cost, i.e. if the cost is $5000 then the whole event should raise $10,000 to pay the cost and make 100% profit. This value is stored in newevent->profitp.
Desired profit fixed amount – A floating point number of dollars (must be >= 0). This indicates that the user cannot plan to lose money on the event. This value is stored in newevent->profita.
Chosen venue for event – integer venue code of the venue where the event will be held. Store in the list at newevent->evenue. This is determined by the program and stored.
Event name – a string less than 40 characters long that gives the event name. The string will be read in with a getline command into a temporary string. The length of the string should be checked using the strlen command. If the string is less that 40 chars in length then it should be copied to newevent->eventname.
Next event – a pointer to another struct event.
Input Implementation: For Lab #5 the user must enter at least the minimum number of venues and events. Since the user has no maximum, the program will NOT ask for the number of inputs. The program will simply start accepting inputs once the user chooses an input method. The program should let the user enter data for one venue (or one event) then ask the user if they have more data to enter or if they are done. The program must keep count of the entered data to make sure the minimum is entered. [Note for development: start with a smaller number of events then increase to the required minimum when program is working well.] You may enter venues and events in the same loop or you also have the choice to make two separate loops; one to enter all of the venue data for all venues and then one to enter all event data for all events.
For Lab #5, you must implement line of data input and file input. The first method will allow the user to input all needed pieces of data about one event on one line, and the second method will read lines of data from an input file. The two forms of the input are described below. The program must ask the user how they want to input the data. Your program must give them all available choices of methods: File input method and line of data input method or both. Once the user has chosen the method of input, all the input will be done that way for the current run of the program.
For Lab #5 you must implement command line parameters to do the following. If the user has entered any command line parameters other than the executable name, i.e. a.out, then the program should assume that the first parameter after a.out is the name of an input file. The program should open this file and check to make sure the file pointer is valid. If it is, the program should read all input from the file. In this case, the program would NOT ask the user about what kind of data entry the user wants. The program SHOULD print out a message saying, ÒYou entered file name ÒLab5stuff.txtÓ (using the appropriate file name) on the command line. It will be used for input.Ó If the file name is not valid or if there was no command line parameter, then the program should let the user choose any of the implemented input methods listed below including file input.
For most pieces of data that are entered, you will do some error checking. It is recommended that your write small functions that you call to do the error checking. This would allow you to reuse these functions when you are updating data in the lists during the menu-driven phase of the program.
Line of data input method:
Your program may ask the user to enter all the information for one venue and/or one event per line. Both may be on the same line or you may ask about venues first one per line then events one per line. The venue and event info would be all the pieces of data listed above. You must tell the user exactly how to enter the line of data.
The data for a single venue and event will be entered by the user as values on one line (or two lines) as follows {there must be one space only between the values}. Here's an example:
prompt> 0104 L 1 F 400 0.45 1.00 0.75 500 Bluebonnet Ballroom UTA 24 2 2012 G A 7 9600.00 0.1 1000 ACM Annual Dinner
which represents the UTA Bluebonnet Ballroom (code 0104, name ÒBluebonnet Ballroom UTA", Large room) with one kind of seating (Festival) and 400 total seats. 45% of the seats will be discounted and 100% of discounted tickets are expected to be sold and 75% of regular price tickets. The hourly rental is $500. The event is on Feb. 24, 2012 and it is an Average sized, Group participation event called the ACM Annual Dinner. The event timeline is 7 hours, the fixed costs are $9600.00, the desired profit is 10% and $1000. If your current struct venue pointer is newven then you would store the venue in newven->vcode, newven->vname, etc.
And a second example: [NOTE: this example is longer because the venue has two kinds of seating instead of one]
> 0221 T 2 S P 850 150 0.1 0.02 0.90 0.75 0.7 0.65 1200 Bass Hall 5 3 2012 A L 12 47000.00 0.4 100000 Lyle Lovett and his Large Band
which represents Bass Hall (code 0221, name ÒBass HallÓ, Theater) with two kinds of seating (Selected and sPecial) and with 850 and 150 seats respectively. 10% of Selected seats will be discounted and 2% of sPecial seats will be discounted. 90% of discounted Selected tickets are expected to be sold and 75% of regular price Selected tickets. 70% of discounted sPecial tickets are expected to be sold and 65% of regular price sPecial tickets. The hourly rental is $1200. The event is on March 5, 2012 and it is a Large, Arts and entertainment event, a concert by Lyle Lovett and his Large Band. The event timeline is 12 hours, the fixed costs are $47000.00, the desired profit is 40% and $100,000.
Alternately, you could have the user enter all the venue data first, one venue per line, then all the event data, one event per line. Ex.
> 0104 L 1 F 400 0.45 1.00 0.75 500 Bluebonnet Ballroom UTA Alternate order of seating items is OK. Ex. below
> 0221 T 2 S P 850 150 0.1 0.02 0.90 0.75 0.7 0.65 1200 Bass Hall > 0221 T 2 S 850 0.1 0.90 0.75 P 150 0.02 0.7 0.65 1200 Bass Hall
> 24 2 2012 G A 7 9600.00 0.1 1000 ACM Annual Dinner
> 5 3 2012 A L 12 47000.00 0.4 100000 Lyle Lovett and his Large Band
Regardless of how the data is entered, your program will read the first number and store it in the current struct at the correct location, then read and store the character into the corresponding location in the struct then read the third number, and so on. Your program should read all the numbers, chars, and the string within a minimum number of input commands. Your program should read in as many lines of input for venues and events as the user desires.
File input method:
Your program may ask the user to enter all the information for all the venues and events from a file. The file would have one venue and/or event per line. The data for one venue or event in the file would be exactly the same data you would use for line of data input in exactly the same format.
You must create a data file that contains at least 14 lines of data and you must read the data from the file. To do this requires creating file variables, opening the file and linking it to the file variable, and then reading the data from the file variable using fscanf and getline in the same way that a line of data would be read from the screen.
The first line of the file must have the first venue (or first venue and event) on it. The format of the data in the file should match the format of the data you use for the line of data method. This means that if you have the user enter venue and event data on the same line in line-of-data method that your file should be the same. Else, if you have the user enter only venue data on a line then only event data on separate lines, your file should do the same. You may choose to have a line in between the venue data and the event data with some special value on it that will indicate the end of the venue data and the beginning of the event data, e.g. 999999.
If the user chooses file input, then your program must first get the name of the input data file to use or have the file name from the command line. You the user has chosen file input without giving a file name on the command line, then you must ask the user for the file name and you must let the user type in a string with the name of the file in it and then use the string as the file name to set up the file pointer. You would read in the name string using getline in the same way you read in the destination name.
Your program needs a FILE * pointer which is connected to the file with fopen. Ex:
int filenm = 100;
char *filename;
FILE *infile;
printf("Please enter the complete name of your data file: ");
getline(&filename, &filenm, stdin);
if (filename != NULL)
infile = fopen(filename, "r");
Input verification:
When the user has entered their specified number of venues and events, print out all the input data in an easily readable form, ex. use a table with headings, or columns with headings or rows with labels. It is strongly suggested that this printing be written as a separate function that can be called at any time in the program to print the current contents of the lists. It is also suggested that a small function be written which will print the name of a venue given the venue code as input. The function could have a switch or a bunch of if statements in it.
Task Description: (Menu-driven phase)
Once all the data is read into the lists your program should give the user a main menu with the following choices: (use any number scheme you wish)
A) Print all the data for all venues
B) Print all the data for all events
C) Print all data for a single venue
D) Print all data for a single event
E) Determine the best venue for an event
F) Calculate price to charge for tickets
G) List all the venues that cost less than a given amount per hour
H) List all the venues that are larger than a given size
I) List all the venues that are in a given city as determined by the venue code
J) Search for a venue by venue type
K) Search for a venue by the type of seating that is available
L) Search for an event by the size of the event
M) Search for an event by the type of the event
N) Search for an event by the cost of tickets
O) Sort the venues by venue code
P) Sort the venues by total seating
Q) Sort the events by date
R) Sort the events by length
S) Update the data in the lists–this will take the user to a submenu for doing updates
T) End the program
The print functions let the user select to print one venue or event or all of them. These functions should call the function that is discussed in the input verification section above.
The determine-best venue function will look at features of the venue and the event to determine the best match. The best matching venue shall be stored with the event as the chosen venue. The decision procedure is:
Look at event setting, add up all the seating in the venue and compare:
If venue seating is less than minimum size of event setting,
then do not choose the venue
If venue seating is more than 50% larger than maximum event setting size,
then do not choose the venue
For venues that fit,
Choose the venue that is closest in size to the maximum event setting size and meets the following requirements:
If event is Sports,
then venue must be B, F, O, or M type
If event setting is Intimate,
then venue must be T, A, C, L, or S type
If event type is Group Participation,
then do NOT choose A type
Else choose the venue closest in size that doesnÕt violate any rules.
The calculate-price function has the following steps:
For each combination of regular and discounted tickets with a seating type, determine the expected number of tickets as:
the number of seats times the percentage of seats they expect to fill of that ticket type divided by 100 and save this value.
Ex: if there are 850 Selected seats, and if the user input 10% discounted seats then the number of discounted seats is 850 * .10 = 85. Out of those seats we expect to sell 90% of the tickets so 85 * .9 = 77. So we expect to sell 77 discount Selected seat tickets. All remaining calculations would be similar (850 – 85 = 765 regular seats, 765 * .75 = 573 which would be 75% of the regular Selected tickets) We will call these values:
numRS for number of Regular Selected tickets,
numRF for Regular Festival tickets,
numRP for Regular sPecial tickets,
numRB for Regular Box tickets,
numRV for Regular VIP tickets,
numDS for Discount Selected,
numDF for Discount Festival,
numDP for Discount sPecial.
numDB for Discount Box, and
numDV for Discount VIP.
You might want to create two members in the seating struct to hold regular numR and discounted numD ticket amounts so you can store these once they are calculated.
Once the ticket amounts are available, the ticket price is calculated as follows:
Add the fixed event costs plus (event length hours * venue cost per hour) to get total cost
Multiply desired percentage profit times total cost to get desired percentage amount
Add the total cost, the desired percentage amount and the desired fixed profit amount to get
profit plus expenses (P&E)
There will be a fixed ratio of ticket pricing as follows:
The basic ticket cost is considered to be the Regular Selected ticket cost (call this RS).
The price of a Regular Festival (RF) will be 50% of the RS price.
The price of a Regular sPecial (RP) ticket will be 300% of the RS price
The price of a Regular Box (RB) ticket will be 500% of the RS price
The price of a Regular VIP (RV) ticket will be 80% of the RS price.
Ticket discounts are: Selected (DS) 15%, Festival (DF) 30%, sPecial (DP) 5%, Box (DB) 2%, VIP (DV) 50%
The total amount of money that is estimated to be brought in is the result of ticket sales. The equation is:
RS*numRS + RF*numRF + RP*numRP + DS*numDS + DF*numDF + DP*numDP + RB*numRB + RV*numRV + DB*numDB + DV*numDV
The num values will all be known or calculated from known values. The ticket prices are what we need to calculate. All the ticket prices are based on RS. So if we rewrite the equation in terms of RS we get:
RS*numRS + (RS*.5)*numRF + (RS*3)*numRP + (RS*5)*numRB + (RS*.8)*numRV +
(RS*.85)*numDS + ((RS*.5)*.7)*numDF + ((RS*3)*.95)*numDP + ((RS*5)*.98)*numDB + ((RS*.8)*.5)*numDV = ticket sales
The goal then is to find a value for RS such that ticket sales >= P&E while keeping the tickets within purchasing range.
If we collect terms in the ticket sales equation we get to:
RS*(numRS + (.5)*numRF + (3)*numRP + (5)*numRB + (.8)*numRV + (.85)*numDS + (.35)*numDF + (2.85)*numDP + (4.9)*numDB + (.4)*numDV) = ticket sales
Now we set this equation equal to P&E which is known and we can try to find a value of RS to make the equation work:
RS = (P&E) /
(numRS + (.5)*numRF + (3)*numRP + (5)*numRB + (.8)*numRV + (.85)*numDS + (.35)*numDF + (2.85)*numDP + (4.9)*numDB + (.4)*numDV)
If we can find RS, we now have the Regular Selected ticket price and all other prices can be calculated from that.
Once these values are calculated, they should be stored in the list.
The list-all-less-than-cost function should ask the user to enter an hourly venue cost maximum then go through every venue and print the complete information for all venues that have an hourly cost equal to or less than the userÕs entered cost.
The list-all-larger-than function should ask the user to enter a size, i.e. a total amount of seating the venue must exceed. The function then goes through the venues, calculates total seating of each venue, and prints the complete information for all venues that have more than the requested amount.
The list-all-in-city function should ask the user to select a city and then go through every venue and print the complete information for all venues that have are in the selected city.
Searches: All searches on the linked list will be linear searches. You should write ONE linear search function and then write separate test functions for each kind of search. These test functions should be passed into linear search as function parameters for each search.
The search-by-type function should ask the user for a selected venue type and then use linear search to look through the venues to find the first venue that matches that type. The function should print the complete info for that venue or print a message that no venue was found.
The search-by-seating function should ask the user for a selected seating type and then use linear search to look through the venues to find the first venue that has that type of seating. The function should print the complete info for that venue or print a message that no venue was found. The list should be sorted by seating type before performing this search.
The search-by-event-size should ask the user for a selected event size and then use linear search to look through the events to find the first event of that size. The function should print the complete info for that event or print a message that no event was found.
The search-by-event-type should ask the user for a selected event type and then use linear search to look through the events to find the first event of that type. The function should print the complete info for that event or print a message that no event was found. The list should be sorted by event type before performing this search.
The search-by-event-ticket-cost should ask the user for a maximum ticket price and then use linear search to look through the events to find the first event with tickets less than or equal to that price. The function should print the complete info for that event or print a message that no event was found. Note that the cost of the tickets has to be calculated for this to work. This function should call the calculate price function for each event in order to make sure that all events have ticket prices. The list should be sorted by ticket cost before performing this search.
Sorts: Sorting on the linked list will be either by bubble sort or selection sort. You should write ONE bubble sort function and then write separate test functions for each kind of sort. These test functions should be passed into bubble sort as function parameters for each sort. If you also choose to implement selection sort, you should create one sort function with multiple test functions.
The sort-by-total-seating function should sort the venues in descending order by total amount of seats using the bubble sort or the selection sort algorithm. The function should print the sorted list when this is done. If selection sort is used, you will need to use additional external pointers to keep track of the location to select in each iteration.
The sort-by-venue-code should sort the venues in ascending order by venue code using the bubble sort or selection sort algorithm. The function should print the sorted list when this is done.
The sort-by-event-length function should sort the events in order from shortest to longest using the bubble sort algorithm. The function should print the sorted list when this is done.
The sort-by-date function should sort the events in date order from earliest to latest using the bubble sort algorithm. The function should print the sorted list when this is done.
Sorting dates is a little tricky because it takes more than one comparison between each date but it is easier done in steps like the following:For any two events being compared,
If the year of event A is greater than the year of event B
Then A is later than B,
Else if the year of event A is less than the year of event B
Then B is later than A
Else if the month of event A is greater than the month of event B (years are same)
Then A is later than B,
Else if the month of event A is less than the month of event B
Then B is later than A
Else if the day of event A is greater than the day of event B (months are same)
Then A is later than B,
Else if the day of event A is less than the day of event B
Then B is later than A
Else
A and B are on the same date (and they can stay in the same order they are in)
For the selection sort, you should keep track of the latest date you currently have in the current pass and that is the value that is swapped on that pass.
The update option should take the user to a second screen to allow them to update information in the arrays. This screen should print the venues and events in the database for them to choose from, ask whether they wish to update a venue or an event, get the appropriate info from the user for that data, and search for that item. Once the correct event/venue is determined save a pointer to its location and give the user a menu of the following options. NOTE: for Lab #5 the user may choose to add or delete seating types within a venue.
o Change a venue size code
o Change a venue type of seating and/or the amount of those seats
o Add an additional type of seating and associated data for this venue
o Delete an existing type of seating and associated data for this venue //ÓDeleteÓ means remove the values and replace them with 0s or other default values
o Change a venue hourly rental amount
o...Change percent of discounted tickets expected to be sold for a given seat type
o...Change percent of regular tickets expected to be sold for a given seat type
o Change the event date
o Change the event size
o Change the event length
o Change the event fixed cost
o Change the event profit percentage or fixed amount
o Add a new venue
o Delete a venue //ÓDeleteÓ means remove the struct from the linked list
o Add an event
o Delete an event //ÓDeleteÓ means remove the struct from the linked list
o Return to main menu
The add function should allow the user to create a new struct, fill it with data, and put it in sorted order in the linked list. After each change is made, print all of the new info.
The delete function allows the user to specify a struct to remove and then remove that from the list. After each change is made, print all of the list info.
For any change the user wishes to make, do the same error checking as in the original data entry section. After each change is made, print all of the info in the current struct [Hint: If you write your data entry section with little functions for each input check then you can reuse them all here.]
When the user chooses "End the program" from the main menu, print a concluding message and then gracefully end the program.
***************************
You should design your program in advance before you begin writing code. In this lab and all other labs you will document your design and turn in the design document at least a week before the lab assignment is due. The goal of the design document is to assist you in developing the actual program.
Read ALL of the assignment before you start trying to develop the program.
Be sure to check the DEDUCTIONS section at the end of this assignment to avoid penalties. You may NOT use global variables, the exit command, goto, break (except in a switch), or continue.
Develop your program in small steps. Test and debug as you go.
Implementation Requirements:
For Lab #5 WRITE A DESIGN DOCUMENT FIRST. The design must include
a) all the functions you expect to write,
b) brief (one line) descriptions of each function, and
c) some indication of which function calls what other functions.
The design document may be written as lines of text or as diagrams (such as a diagram that start with the main function at the top and all others below it) or as some combination of those, but it must include the information listed for a), b), and c) above. Each function should accomplish one main purpose and each function at a lower level should have a more specific purpose than the function that calls it. Be sure to include all the functions that are described in this lab assignment. This design documentation will normally be turned in for the lab and a design will be required to be turned in for all labs after Lab 1. See the website or this assignment for the DESIGN DOCUMENT due date. It is usually ONE WEEK PRIOR to the lab due date.
A Lab #5 Design Document must be turned in in order for your Lab #5 assignment to be graded.
For Lab #5 you must also write and turn in a TESTING PLAN along with your design document. The testing plan should include at least five (5) sets of test data values that will test at least the following elements of your code:
Test the data entry number validation for day, month, year
Verify the length of an event name
Demonstrate correct calculation of ticket prices
Demonstrate correct sorting of the linked list
Demonstrate a search that does NOT find a matching value
Give your set of test values for each test element above and indicate what the correct result of the test should be and how to demonstrate that this result has occurred, i.e. will the user have to ask for the data to be printed out or will that happen automatically?
The program should use the following data structures:
Linked list of structs
Global CONSTANTS for specific and/or maximum values given in this assignment.
Constants can be done with #define or with the const declaration. Examples:
#define EVENTMAX 10
const int EVENTMAX = 10;
The program should use the following control structures:
Function calls to perform tasks
While, for, or do-while loops to read the input data
If, if-else, nested ifs, or switches to error check and implement the menu options
The program should NOT use:
global variables
exit
break (except in a switch)
continue
any topic not covered in class before the lab DUE date unless approved by the instructor
Programming practices:
Comment your code! Use headers as described below, use line comments and use block comments. Line and block comments should explain the meaning of the code. As an example compare the following examples of code with comments:
Example 1:
/* Find A by multiplying L times W */
A = L * W; // A is the product
Example 2:
/* Find the area of the rectangle by multiplying length times width of the sides */
A = L * W; // A is area, L is length of one side, W is length of perpendicular side attached to L
While Example 1 has comments, the comments do not tell us anything extra about the code. The code itself tell us that A is the product of L*W. In Example 2, the comments are meaningful and explain the goal of the code and the meaning of the variables. Make your comments like Example 2 not Example 1.
The program should have a program header which gives, at least, your name, the number of the lab assignment, your class and section, the assignment date, the due date, and a description of the program. If multiple files are used, each file should contain a similar header.
Each programmer-defined function, i.e. each function you write, should have a function header similar to those used in the examples in the textbook. This header should include at least the function name, the purpose of the function, and its inputs and outputs.
The program should be implemented as a set of functions with a main routine and at least one function for menu operations, two for getting input, one for printing, and all of the functions listed for the user choices. You may use many more functions than this but you must use at least this many. The purpose of functions is to divide the problem into small tasks, each one assigned to its own function and then to call the functions from main() or from another function when appropriate. Do not code the entire program in main!
For Lab #5, you must split your program into at least three separate program files as follows:
All constants and type definitions in one file,
The main routine and the functions prototypes in one file, and
The remaining functions in one or more physical files.
Compile them all together with any combination of #include statements, extern commands or with multiple files on the gcc command line to create the output a.out
The program should perform the following actions in the given order:
Declare and initialize the variables
Print a welcome screen for the user that introduces the system
Get the needed input values from the keyboard or file
Print the appropriate outputs
Let the user make additional choices until the user indicates that they are finished.
Output requirements:
The program must be run and the output recorded in a script file from OMEGA using the gcc compiler. No Exceptions! If you do not know how to create a script file, it is your responsibility to ask the TA, look for help on the class website, or OIT how to use this function.
You must come up with information to use as test data for at least the minimum number of venues and events. You may only have two venues that have only one kind of seating - all other venues must have multiple kinds of seating. Please use real data for venues and events. Feel free to use venue websites to "plan" the event data for this lab. See the Miscellaneous section below for other useful info.
Testing:
This program must be run with the different sets of test data as given in your test plan for the input data You must create two different data sets and run your program with both of them. I will give you a small amount of sample data at the end of this lab for you to use as a model. You may run your program two times within a single execution or you may execute the program two different times so that you have at least a total of two different data sets. The sample data sets that you create must meet the guidelines given in the problem definition. Your test runs should demonstrate all the choices that are available in your program.
NOTE ABOUT ERRORS:
Programs turned in for credit MUST compile and run WITHOUT any compilation errors or runtime errors using the gcc compiler on omega. No other compiler may be used for the compilation for credit. No other operating system may be used for the compilation and/or execution for credit.
Compilation errors occur while the program is being developed and they prevent the program from compiling correctly. Programs compile correctly when running
>gcc myprogram.c
or
>gcc mymainprogram.c myheader.h myfunctions.c
gives no error or warning messages.
Programs may be turned in for credit when they are partially complete but all completed functions must run without any errors. A program completes without runtime errors if it ends only when the user selects for the program to end and it correctly prints the exit message. Partially complete programs that run correctly for all implemented menu choices will receive partial credit.
Any other type of ending is a runtime error or a "crash". A program has a runtime error if it compiles and runs but then crashes in any situation, i.e. if there is any set of legal choices the user can make that will make the program crash. It is your responsibility to test all possible choices in your program to make sure that none of them cause a runtime error. The goal of creating input test data and running your program with it should be to test all of the various choices in your program to make sure all of them terminate correctly. For Lab #3 you, the programmer, are not responsible for errors of data type committed by the user in the input data. You are responsible for errors of data value in the input data.
Labs which have errors in them and do not terminate normally will receive an overall grade of 0 (zero)
Grading Scale:
Code: (56%)
Program header and function headers for all functions (2 points)
Comments (line comments and block comments) (3 points)
Modularity (division of the problem into small tasks, each one assigned to its own function and called from main() or from another function when appropriate--do not code the entire program in main!) (3 points)
Style (indentation, consistency, meaningful identifiers, lateral separation of code from line comments, etc.) (2 points)
Correct definition of the struct data type for venues, events, and seating (3 points)
Correct manipulation of the struct data type for venues, events, and seating (4 points)
Correct construction of sorted singly linked list (6 pts)
Correct use of command line parameters for filename input (4 pts)
Correct test condition functions written for search and/or sort (3 pts)
Correct use of pointers to functions for passing in test condition functions to search and/or sort (3 pts)
Correct use of multiple files as defined (4 pts)
Proper implementation of file input and input error checking (4 points)
Proper implementation of line of data input including error checking (4 points)
Correct implementation of bubble sort algorithm (3 points)
Correct implementation of selection sort algorithm (2 points extra if used)
Correct implementation of linear search algorithm (2 points)
Proper implementation of data update and error checking
Change values (2 pts)
Add values [venues, events or seating] (2 pts)
Delete values (2 pts)
Output: (44%)
User clearly understands what is being requested for input (3 points)
Linked list correctly developed initially (3 pts)
Linear Search tasks perform correctly with test functions passed in (4 points)
List-all tasks perform correctly (2 points)
Revised calculate tasks perform correctly (3 points)
Bubble Sort tasks perform correctly with test functions passed in (4 points)
Selection Sort tasks perform correctly (2 points extra if implemeted)
Linked list correctly manipulated for sorting and updates (5 pts)
Update – make changes - tasks perform correctly (2 points)
Update – additions - tasks perform correctly (2 points)
Update – deletions - tasks perform correctly (2 points)
Input verification shows valid values and list of inputs correctly saved and printed (2 points)
Output gives clear information to explain the values to the user (2 points)
Output follows test data plan (2 pts)
Output contains all test data set as defined (2 points)
Two test data files turned in with assignment (4 points)
Grading Deductions:
Use of global variables will result in an overall grade of 0 (zero) [-100 deduction]
Use of the exit, break (outside a switch), or continue command will result in an overall grade of 0 (zero) [-100 deduction]
Labs which cannot be compiled or do compile with warnings will receive an overall grade of 0 (zero) [-100 deduction]
Labs which have errors in them and do not terminate normally will receive an overall grade of 0 (zero) [-100 deduction]
Missing design document will result in an overall grade of 0 (zero) [-100 deduction]
Missing test plan document will result in 50 point deduction [-50]
Late submission of softcopy of code and/or script file will result in an overall grade of 0 (zero) PERIOD for Lab #5
Use of C language elements not yet discussed in class by the lab due date will result in potential deduction of points - discuss with instructor before using.
Miscellaneous:
Venue code structure: The code will be a 4-digit number. The leftmost two digits (1,000s place and 100s place) will indicate the city as follows:
01 Arlington
02 Fort Worth
03 Dallas
04 Irving
05 Plano
06 Garland
07 Grand Prairie
08 Carrollton
09 Other city in center of Metroplex
10 Other city on east side of Metroplex
11 Other city on west side of Metroplex
12 Other city on north side of Metroplex
13 Other city on south side of Metroplex
14 Other North Texas city
15 Other Texas city
20 Other US city
Following the city value will be a value in the 10s and 1s places that indicates one of the below. The codes for those digits will be:
01 College Park Center
02 Lone Star Theater
03 Texas Hall
04 Bluebonnet Ballroom
11 Levitt Pavilion
21 Bass Hall
22 Will Rogers Auditorium
23 Fort Worth Botanical Gardens
31 Myerson Symphony Center
40 Any other venue in DFW area
50 Any other venue in North Texas
70 Any other venue in Texas
90 Any other venue in the US
Therefore the venue code for the UT Arlington Bluebonnet Ballroom is 104 (or 0104 if you want) and the code for Radio City Music Hall in NY, NY would be 2090.
Sample input:
0104 L 1 F 400 1.00 0.75 500 24 2 2012 G A 7 9600.00 0.1 1000 Bluebonnet Ballroom UTA
0221 T 2 S P 850 150 0.90 0.75 0.7 0.65 1200 5 3 2012 A L 12 47000.00 0.4 100000 Bass Hall
0104 L 1 F 400 0.45 1.00 0.75 500 Bluebonnet Ballroom UTA 24 2 2012 G A 7 9600.00 0.1 1000 ACM Annual Dinner
0221 T 2 S P 850 150 0.1 0.02 0.90 0.75 0.7 0.65 1200 Bass Hall 5 3 2012 A L 12 47000.00 0.4 100000 Lyle Lovett and his Large Band
Or
0104 L 1 F 400 0.45 1.00 0.75 500 Bluebonnet Ballroom UTA Alternate order of seating items is OK. Ex. below
0221 T 2 S P 850 150 0.1 0.02 0.90 0.75 0.7 0.65 1200 Bass Hall 0221 T 2 S 850 0.1 0.90 0.75 P 150 0.02 0.7 0.65 1200 Bass Hall
24 2 2012 G A 7 9600.00 0.1 1000 ACM Annual Dinner
5 3 2012 A L 12 47000.00 0.4 100000 Lyle Lovett and his Large Band
Your test data should be drawn from real venues and events. Go online and look up some locations and some types of events that occur there and use that for your data. Mix up the events and venues when you enter the data.