This is the first of three projects based on the GusAir case study. You should have read the background document. For this first project, your goal flows from the following paragraph of that document:
The simplest option would be for GusAir to advertise a fixed price for a ticket. To assess this option, we have been asked to find out what price would maximize revenues. (Too high a price will leave seats unsold.)
Some of the homework problems asked you to think about this, which served as a basis for our class discussion. The following sections include a summary of portions of that discussion, as well other useful information and the specific expectations I will use in grading your project report.
We discussed a general strategy for finding the revenue maximizing price:
Have some way of calculating the expected revenue for a particular price.
Use that way to try different prices until the price that maximizes the expected revenue is found.
More specifically, we discussed two different approaches to finding the expected revenue for a particular price:
One approach is to use Monte Carlo simulation. For each of a large number of simulated flights, step through the hours of ticket sales, totaling up the revenue earned. Take the average over the large number of simulated flights.
The other approach is to calculate (based on a mathematical analysis) what the probability is of selling 0 tickets, 1 ticket, 2 tickets, etc., and then multiply each probability by the corresponding revenue and add them up.
Similarly, there are lots of different strategies for how to select what prices to try. All of the ones we discussed in class start at some low price and work consecutively upward, stepping by 1 dollar each time. (Some other approaches might try non-consecutive prices to more rapidly find the optimum.) For consecutive search, we discussed starting at 0 or at some other value you were sure was well below the optimum price. We discussed several possible stopping criteria:
You could stop when the price reached some value you are sure is too high.
You could stop when the expected revenue drops below some threshold.
You could stop when the expected revenue stops below some fraction of its peak value.
Whatever strategy you use, be sure to check your answers with other students who are using different strategies. And remember, our clients at GusAir probably don't want to know just the revenue maximizing price. Surely they'd like to know the corresponding expected revenue. And if we could offer them a table or graph showing how the expected revenue is influenced by the price, that would be even better. For this purpose, it might be useful to output the prices and revenues as a CSV (comma-separated values) file, which can be read into a spreadsheet program. There is a Python module that you can use for writing out a CSV file.
In order to calculate the probability a potential customer will find a price acceptable, you will probably want to include the following line at the top of your script:
import math
That way, you will have access to the constant math.e. Alternatively, you can use the function math.exp.
If you are using the Monte Carlo approach to calculating expected revenue, you'll also want to preface your script with
import random
so that you have access to random.random().
If you want to use the csv module to write out a CSV file that can be loaded into a spreadsheet, the following example should help you see how to do this. This example creates a file called squares.csv that contains a table of the integers from 0 to 9 with their corresponding squares:
import csv
output = open("squares.csv", "wb")
writer = csv.writer(output)
for i in range(10):
writer.writerow( (i, i**2) )
output.close()
Your project report will be graded based on the following expectations. Ten percent of your grade will come from each of these ten areas; for extra credit, you can provide tabular or graphical information on how the expected revenue depends on the price.
You are to state what problem you have solved, in language that would be clear to a mathematically literate reader who is not familiar with the project assignment. This requires you to succinctly summarize in your own words some of the material in the GusAir background document. Much of that document concerns simplifying assumptions you were allowed to make; rather than stating all of those explicitly, it would be appropriate to leave most or all of them implicit by stating what you did take into account and remaining silent about what you didn't take into account. Also, you can focus exclusively on the problem addressed by the current project, remaining silent about what still lies ahead for future projects.
You are to explain what approach you took to calculating the expected revenue corresponding to any particular price. This explanation should include a brief statement of the advantages and disadvantages of the approach you chose.
You are to explain the approach you took to selecting different prices to try in order to find which one yields the greatest expected revenue. You should explain why you chose this approach, which will presumably entail briefly comparing it with alternatives.
You are to explain how you gained confidence in your program's results. This should include comparison with other students' results, which you should put in context by indicating how different their strategic approach or programming style was from your own. You should also subject your results to basic "sanity checking": Are they plausible? Also, you ought to check whether the expected revenue your program calculates for low and high prices matches our understanding of the shape of the revenue curve.
Your search for a revenue-maximizing price should be programmed, rather than being a matter of your manually querying the revenue for various prices. That way, if GusAir were to change some parameter, we could just re-run your revenue-maximization procedure and get the new answer.
Your code should have all numerical parameters clearly separated out and named, so that if our clients were to change their mind about such things as the plane size, ticket sale period, or demand model, all that would need changing are the values of a few descriptively named variables that are set at the top of the script.
Your code should be divided up into cohesive procedures, each focused on a particular aspect of the problem solution. The procedures should coupled together by well-defined interfaces. That is, the coupling should be through meaningful arguments and return values, which should be documented in the procedures' documentation strings. There should not be any coupling through modification of global variables. (The only global variables should be for the problem's parameters, which are not modified during the program's execution.)
If your approach to calculating expected revenues could accommodate time-dependent demand, then your code ought to be structured so as to make this change easy and obvious. (In particular, relevant procedures may need to take the time as an argument, even if they currently make no use of that argument.) On the other hand, if your approach to calculating expected revenues cannot accommodate time-dependent demand, then you ought to make this fact explicit with a brief explanation.
Your procedures should not only be free of bugs, but also as simple and clear as reasonably can be achieved.
Your project report should use devices such as section headings to provide a clear organizational structure. Despite containing all of the explanatory information mentioned earlier, your report should still make it easy to find what the revenue maximizing price and corresponding revenue are.