Lab 3: Table Specifications

Learning objectives

This lab is designed to give you practice with planning, testing, cleaning, and writing table programs that are more in line with what's on the homework. There will be a lot of paper/worksheet work for this lab. Take it seriously: we genuinely believe these paper tasks will help you build programming-related skills. They give you practice in lab with the level of work we are expecting to see on the homework and on exams this semester. And, to the point of the course, they practice the kinds of skills you'll need to design larger programs with agents as the semester goes on.

This lab asks you to:

write constraints for a set of tables
critique and identify good features of example code plans
develop a testing plan and use the tests to flag incorrect solutions
implement a function using a plan that was handed to you
find the errors in a program that was written by someone else

You may well not get through all of this lab, and that is fine. Work with your partner, and understand the code you write rather than racing to the last task.

Setup

Find a partner.
Open the starter file in Pyret, which loads the three tables, and save a copy of it.
Make a copy of the written answer worksheet, share it with your partner(s), and submit the link to it in the worksheet submission form (you can do this before filling anything in).

Problem context: The debate league

A league of eight colleges runs a season of four debate tournaments. In each round one team argues for a resolution and one argues against it. Three judges each cast a ballot; whichever side gets the most votes wins. You have access to the data tables for the tournament. We'll be designing programs and tests for various analyses about the debate season.

Part 1The data

The season is recorded in three tables. Two sample rows from each are shown below.

schools: one row per school (8 rows).

schools
school	region	enrollment
Harlow College	Northeast	2400
Calloway College	Mid-Atlantic	1800

teams: one row per team (18 rows).

teams
team-code	school	debaters
HAR-A	Harlow College	Larsen & Tanaka
WEX-A	Wexford University	Dubois & Quinn

rounds: one row per round (125 rows). In the column labels, AFF is short for "affirmative" (they argued for the resolution), while NEG (for "negative") argued against the resolution. The winner names a side ("aff" or "neg"), not a team. If a round didn't happen (a "bye"), either the AFF or NEG team would have a blank cell (that side didn't show). In those cases, the ballots should be 0 and 0.

rounds
tournament	round	aff	neg	aff-ballots	neg-ballots	winner
Fall Open	1	SVU-B	HAR-A	1	2	neg
Fall Open	1	WEX-A	HAR-B	3	0	aff

Task 1

Work out a set of Constraints that you think should be on the data in these tables. Write your answer in your Worksheet.

Part 2What makes a good plan?

An upset is a round where the winning team finished the season with a lower win percentage than the team it beat. Here are two plans for identifying the upsets:

Plan A

Get rid of the rounds that don't count.
Figure out how good each team is.
Compare the two teams in each round.
Keep the rounds where the worse team won.

Plan B

Filter out the byes.
Calculate the win percentages.
Add the winner and loser.
Add their percentages.
Filter to the upsets.

Task 2

Critique these plans. If someone gave one of them to you to implement, is there anything you'd find missing or unclear in them? Are there details you think are missing? Are there things one does better than the other? Make a list of your observations about these plans in your worksheet.

Task 3

Now, open Plan C. Contrast it to plans A and B. Are there things that C does better? Things is does less well? Write your answer in your worksheet.

Plan C

Remove the byes from the rounds table, using filter-with, since no debate happened in them.
Work out each team's win percentage.
Using build-column, add a column to the rounds table naming the winning team, and another naming the losing team.
Add each team's record to the rounds.
Keep only the rounds where the winning team's win percentage is lower than the losing team's, using filter-with.

Task 4

Based on your observations, write down your criteria for good plan statements. Put your list in your worksheet.

Checkpoint

Have a TA check your work.

Part 3What makes for good tests?

Now, let's think about testing. Someone wants a program called wins-for that takes a table and a team-code (from the teams table) and returns the number of wins for that team within the tournament.

Task 5

Make a list of the situations that would be good to cover in a testing table for this problem. Put this in your worksheet.

Task 6

Here is a link to a different Pyret file. Fill in the table that's started there with rows that exercise your situations. You may add other tables too, if you want.

Task 7

Now, fill in the check block in the file with a set of tests for wins-for against the table(s) you designed. Do not implement wins-for, just write the table and the check block. When you run the file, Pyret will use your check block against several good and bad versions of wins-for that we wrote. This is exactly what happens with the "buggies" in the autograder. Improve your tests until to catch most of the buggies.

Checkpoint

Have a TA check your work.

Part 4Implementing From a Plan

After the season is over, the organizers want to compile the records for each team. They want a program called team-records that takes the teams table and the rounds table, and produces the teams table with three new columns summarizing each team's season. Specifically, for each team, they want to know:

wins: how many rounds the team won;
rounds: how many rounds it debated in, whether it argued aff or neg;
win-pct: its wins as a fraction of its rounds.

Byes don't count toward either wins or rounds, because no debate took place. A team that never debated has a win percentage of 0. Once they have the table, they want a bar chart of win-pct per team.

Here is a concrete plan for writing this program:

Remove the byes from rounds, using filter-with.
Starting from teams, use build-column to add a wins column: the number of rounds from step 1 that the team won.
Use build-column to add a rounds column: the number of rounds from step 1 the team debated in, on either side.
Use build-column to add a win-pct column: wins divided by rounds, or 0 when the team has no rounds.
Then make a bar chart of win-pct by team.

Task 8

Implement the plan, one step at a time. Label each step in your code with a comment, such as # step 1, etc.

Checkpoint

Have a TA check your work.

Part 5Using tests to debug a program

Someone has written the following function that computes the percentage of rounds that the teams from a particular school won. If a school played no matches, the program returns 0.

school-win-pct(teams :: Table, rounds :: Table, school :: String) ->
Number

Your job is to determine whether this program is working, without the aid of AI. You've learned about code and testing plans, and about writing small test tables. You'll need to decide how to make use of these methods to help you figure out whether (a) the program is correct (you gain confidence in the code and would recommend using it as part of next year's budget allocations) or (b) the program has an error, in which case you should at least describe and ideally fix the issue.

Make a copy of the school-win-pct-audit.arr Pyret file with the implementation.

Task 9

Discuss with your partner: How do you want to go about auditing this code? Discuss approaches with your partner, then note them in your worksheet.

Task 10

Audit the code. Keep notes about what you tried and how it went in your worksheet. The staff will use the worksheet entries to gauge what skills the class as a whole has developed at this point.

Task 11

Give Gemini the original code (you can access the file again at the above link), ask it to audit the code, and see what it produces. Compare your observations to Gemini's -- in your worksheet, make note of what similarities and differences you see to your respective approaches.

Checkpoint

Have a TA check your work.

Getting help

In lab, flag down a TA. You do not have to be stuck to do it, and you do not have to have tried everything first — that is what they are in the room for. Ask early: a pair that spends forty minutes on a typo has lost the part of the lab that was worth doing.

Your partner counts too. Saying out loud what you think the code does is most of debugging, and it is faster than waiting.

After lab, short questions go on Ed, and anything longer is better brought to office hours.

Comments or concerns?

If you have comments or concerns, submit them on the anonymous feedback form. Sign in with your Brown Google account to open it; your email address is not recorded.