CSC108H Assignment 3, Summer 2011

Due Monday, July 25, 11:55 pm

Introduction

The purpose of this assignment is to give you more practice writing functions and programs in Python, and in particular writing code with dictionaries and files.\

You should spend at least one hour reading through this handout to make sure you understand what is required, so that you don't waste your time going in circles, or worse yet, hand in something you think is correct and find out later that you misunderstood the specifications. Highlight the handout, scribble on it, and find all the things you're not sure about as soon as possible.

It is probably worth spending at least a day thinking about the assignment before writing code of any sort. Try to think through potential problems to catch them before they appear. This will save hours of frustrating debugging time.

Hockey Statistics

During a hockey game, statistics are often recorded indicating the performance of the players. These are compiled for analysis, which is used to evaluate players.

We will be taking some very basic stats, and then writing code that generates some more advanced stats and returns some information about them. This will mainly involve dictionary manipulation. Here is a basic guide to advanced hockey stats if you're interested. We won't be dealing with most of these because it's hard to find the raw data to generate them, but it is interesting to read about.

The stats we consider

• Player Name: Indicated by Name. This is the name of the player in a (First Name) (Last Name) format. That is to say the first name, followed by a single space, followed by a last name. Player names will alwasy be unique, and players will never be traded.
• Team Name: Indicated by Team. This is the geographic designation of the team. It is a city if the team is referred to by a city name (like Vancouver for the Vancouver Canucks) but a region if the team is referred to by a region (like Dallas for the Dallas Stars).
• Games Played: Indicted by GP. This is the number of games the player played in. In order for a player to count a game, they must have been on the ice at some point during the game.
• Goals: Indicated by G. This is the total number of goals scored by a player. This includes goals scored while on power plays, and even-strength. For the purposed of this assignment, we consider short-handed goals to be scored at even-strength, so there are only two types of goal.
• Power Play Goals: Indicated by PP. This only includes goals scored while on the power play.
• Time on Ice: Indicated by TOI. This contains the total amount of time the player was on the ice for. This is stored in the format minutes:seconds
• Power Play Time on Ice: Indicated by PPTOI. This contains the total amount of power play time that a player was on the ice for. This is stored in the format minutes:seconds

From these stats we will want to compute a number of advanced stats. If you read the link above, we don't have the raw data to computer some of the more advanced and interesting stats, but the ones we may need to compute are here:

• Goals per Game: Indicated by G/TOI. This is the number of goals scored by a player per 60 minutes of ice time for that player. It is not the number of goals a player scored over the number of games a player played in.
• Even-Strength Goals per Game: Indicated by ESG/ESTOI. This is the number of goals scored by a player per 60 minutes of 5 on 5 (or even-strength) ice time for that player. For the purposes of this assignment, we consider even strength time on ice to be total time on ice minus power play time on ice. That is, to simplify things, short-handed time is considered to be even strength time on ice. Note that this means that the quality of our metrics is not as good as it could be.
• Relative Goals per Game: Indicated by RG/TOI. This is the difference between a players goals per 60 minutes of ice time and the league average. Note here that the league average is determined by taking the total number of goals scored, and the total number of ice time and using that to determine the average. This means that the the league average is not simply the average of the goals per game of all the players. Explictly, the stat is (Player G/TOI)-(League G/TOI). This stats counts as an advanced league stat.
• Relative Even-Strength Goals per Game: Indicated by RESG/ESTOI. This is the difference between a players goals per 60 minutes of even strength ice time and the league average. Note here that the league average is determined by taking the total number of goals scored, and the total number of even-strength ice time and using that to determine the average. This means that the the league average is not simply the average of the goals per game of all the players. Explictly, the stat is (Player ESG/ESTOI)-(League ESG/ESTOI). This stat counts as an advanced league stats.
• Power play ice time per game: Indicated by PPTOI/GP. This stat indicates the average amount of powerplay time a player got. This stat is mainly used to determine how a coach views a particular player. One can use it in conjuction with the Relative Power Play Goals per game (which we are not calculating) to determine if a player is being misused. This stat should be stored in seconds.

Data Source

We will be providing data for you in the form of .csv (comma separated value) files. We will be using US-stlye csv files. You may obtain some here. In the .csv file, the first line of the file will contain column headings that contain all of the basic stat headings listed above. Each column is separated by a , and text fields are indicated by quotation marks. There is no guaranteed order to which stat falls under which heading. While the files we give you have only one team per file, this is also not guaranteed. Subsequent lines contain the data for one player, whose name and team and stats are in the appropriate column.

Note that throughout one run of your program, we may load multiple .csv files.

Your Task

You are to write code that takes csv files and then updates a dictionary of players with the stats contained in that csv file. Your code should also be able to generate advanced statistics, and furthermore it should be able to sort players by statistics.

Note that in this assignment you will be modifying a global variable. You are allowed to create other global variables, if you find it useful. You are to download assignment3.py and complete the code stubs, according to the docstrings. You will also need to define helper functions that are not in the assignment, but the functions given should give you some idea of how to proceed.

Additional requirements

• Where a docstring says a function can assume something about a parameter (e.g., it might say "text is a non-empty list") the function should not check that this thing is actually true. Instead, when you call the function make sure that it is indeed true.
• Do not add any user input or output
• Close every file that you open.
• Text fields in a csv are indicated by quotation marks. You should strip these before entering the data into your database. So you should just store the names, and not the quotation marks.
• You must not use any break or continue statements. Any functions that do will receive a mark of zero. We are imposing this restriction (and we have not even taught you these statements) because they are very easy to "abuse," resulting in terrible code.

How to tackle this assignment

While this assignment is much more reasonable than assignment 2, you'll still need a good strategy for how to tackle it. Here is our suggestion. First download the code from assignment3.py.

Principles:

• To avoid getting overwhelmed, deal with one function at a time. Start with functions that don't call any other functions; this will allow you to test them right away. The steps listed below give you a reasonable order in which to write the functions.
• For each function that you write, plan test cases for that function and actually write the Python code to implement those tests before you write the function. It is hard to have the discipline to do this, but you will have a huge advantage over your peers if you do.
• Keep in mind throughout that any function you have might be a useful helper for another function. Part of your marks will be for taking advantage of opportunities to call an existing function.
• As you write each function, begin by designing it in English, using only a few sentences. If your design is longer than that, shorten it by describing the steps at a higher level that leaves out some of the details. When you translate your design into Python, look for steps that are described at such a high level that they don't translate directly into Python. Design a helper function for each of these, and put a call to the helpers into your code. Don't forget to write a great docstring for each helper!

Advice:

1. Read this handout thoroughly and carefully, making sure you understand everything in it, particularly how the advanced statistics are calculated. Read the code stubs to make sense of the following advice.
2. You need to write your own code to open files, but only add_file_info should do so.
3. You should start by writing code to add the basic stats to player_stats.
4. Note that get_col_names, toi_in_games, and add_player are all helper functions for this basic task.
5. Then try and write code that will update player_stats with the advanced statistics.
6. Finally, write code to return ordered lists of players.
7. Make sure to test the code as you're writing each small bit, so that you can ferret out problems early.
8. The shell can be useful for testing half-written functions.

Marking

These are the aspects of your work that we will focus on in the marking:

• Correctness: Your code should perform as specified. Correctness, as measured by our tests, will count for the largest single portion of your marks.

• Docstrings: For each function that you design from scratch, write a good docstring. (Do not change the docstrings that we have already written for you.) Make sure that you read the Assignment rules page for some important rules and guidelines about docstrings.

• Internal comments: Within functions, the more complicated parts of your code should also be described using "internal" comments. For this assignment, internal comments will be more important than on assignment 1.

• Programming style: Your variable names should be meaningful and your code as simple and clear as possible.

• Good use of helper functions: If you find yourself repeating a task, you should add a helper function and call that function instead of duplicating the code. And if a function is more than about 20 lines long, consider introducing helper functions to do some of the work -- even if they will only be called once.

• Formatting style: Make sure that you read the Assignment rules page for some important rules and guidelines about formatting your code.

Submitting your assignment

You must hand in your work electronically, using the MarkUs system. Log in to it here, using your cdf login and password.

To declare your partnership, one of you needs to invite the other to be a partner, and then they need to accept the invitation. To invite a partner, navigate to the Assignment 2 page, find "Group Information", and click on "Invite". You will be prompted for the other student's cdf user name; enter it. To accept an invitation, find "Group Information" on the Assignment 2 page, find the invitation listed there, and click on "Join". Note that, when working in a pair, only one person should submit the assignment.

To submit your work, again navigate to the Assignment 2 page, then click on the "Submissions" tab near the top. Click "Add a New File" and either type a file name or use the "Browse" button to choose one. Then click "Submit".

For this assignment, hand in just one file:

• assignment3.py

Once you have submitted, be sure to check that you have submitted the correct version; new or missing files will not be accepted after the due date. Remember that spelling of filenames, including case, counts. If your file is not named exactly as above, your code will receive zero for correctness.