|CS 220 01/ Zelle||Winter 2017|
Chapter 1 Review Questions (pt 1) (due 1/13, class time)
Do T/F questions 1--5 and Multiple Choice 1--3 from pp 33,34. Write answers on paper suitable for hand-in at the start of class.
Craps Simulation Design (due 1/16, class
Complete the design for the craps simulation program discussed in class today. The input to the program is a number, n, that tells how many games of craps are to be simulated. The program then simulates n games following the rules of craps (see rules here.).
Your design must have the following functions: main, printIntro, simNGames, simOneGame, rollForPoint, rollDice. For each of these functions you should provide a function header, and appropriate pre-- and post conditions. Your design should be detailed enough that you could turn it over to another class member to implement.
craps.py (due 1/20, midnight)
Write a craps simulation program that conforms to the specifications given in the design here. This program should be turned in on Socrates (Manhattan VC).
function practice (due 1/20, class time
Write a specification and implementation for these two (informally described) functions:
find_kth_smallest(lst, k): finds the kth smallest item in a list delete_all(lst, item): deletes all occurrence of item from a list
Read/study Sections 1.3 (due 1/23, class time)
For many, this is probably the hardest section of the book (honestly). Give it your careful attention and bring your questions to class on Monday.
Chapter 1 Review Questions (pt 2) (due 1/25, class time) Do T/F questions 6--10 and Multiple Choice 4--10 from pp 33,34. Write answers on paper suitable for hand-in at the start of class.
Read/Study Sections 2.1--2.3 (due 1/27, class time)
Reminder: First exam moved to 2/1
Blackjack (aka 21) Simulation (due 2/6, midnight)
Write a Blackjack simulation program that computes the probability that the dealer will bust when starting with a given total. The inputs to the program are the number of "games" to simulate, and the initial point total. The program then simulates that many games and reports the number of times that the dealer busts, as well as the bust percentage.
You can find rules for the game here. As stated in class our dealer will stand with any hand of 17 or better. Your program must make use of the following classes/methods:
Hand your final program in on Socrates. If you split your classes across multiple files, be sure that you hand in all of them.
Start reading/studying Chapter 3
Stacked Deck (due 2/13)
Modify the Deck from Chapter 3 so that it can be "stacked." The Deck constructor will take an optional second parameter that is a filename. If supplied, that file will contain a sequence of cards specified one per line. Each line contains a rank number and a suit character separated by a space. For example a deck consisting of 4 cards could be:
4 c 12 d 14 d 10 c 3 hNote: the cards should be "loaded" into the deck such that they are dealt in order from the top of the file to the bottom.
Using Deck and Hand (due 2/13, class time)
Short answer question #1 on page 102.
Solitaire Sim (due 2/17)
Write a simulation of the solitaire game discussed in class. You can use the Card and Deck classes from Chapter 3. You should also use a SolHand class with the following methods:
def __init__(self): """Creates an empty hand.""" def addStack(self, card): """ puts card in a new stack """ def findPair(self): """ returns a Boolean indicating whether the hand has a pair""" def coverPair(self, card1, card2): """covers a previously located pair with card1 and card2""" def numPiles(self): """returns the number of piles in the hand""" def getTops(self): """returns a list of the cards currently on top of the piles"""
Your program takes as input the number of games to simulate and then for each possible number of piles 2--14 prints the percentage of times that outcome occurred.
Linked Lab (due 2/24, midnight)
This is the CD_lab that was handed out in class. You can find a copy here.
Chapter 5 Review (due 3/6, class time)
Read Chapter 5 and answer the True/False and Multiple Choice questions from pages 181 and 182.
Queue Tests(due 3/8, midnight)
Write unittest code to test queue implementations. You should be sure to address all the test cases that arose during class discussion. You can "test your test code" using the MyQueue implementation from the textbook.
Deck and Solitaire Fixes (due 3/10, midnight)
Resubmisisons of stacked deck and solitaire games.
linkedq.py (due 3/13, midnight)
Implementation of Queue using simple linked list of _Nodes. Make sure your solution passes the tests in the testq.py file (see handouts).
Marble Clock (due 3/17, midnight)
This is a generalization of a problem from the textbook. The project description is here.
Arrow Fractal (due 3/22, midnight)
Complete the "arrow" fractal we discussed in class today. The generator is a "hump" created by tracing the "outline" of two side-by-side equilateral triangles. This generator is alternated similar to the dragon curve, except the first bump is "in" rather than "out". Here are pictures of the level 1, 2 and 3 curves:
wordgrid.py (due 3/31, midnight)
This is the first phase of our final project. We are building a word search game. This first phase involves designing a data structure to represent the game board, essentially a square grid of characters.
Seed code for can be found in our handouts folder in wordgrid.py. This code provides both a specification for the WordGrid class and some docstring-embedded examples suitable for explanation and unit testing. The unit testing is set up to be run automatically using the Python doctest module. When you run the code, you will see that it reports a bunch of test failures, since the methods have not yet been implemented.
I have placed the methods in the order in which they are most easily understood and implemented. You should try to fill in the missing code from top to bottom. The first step is to study the specification and come up with a concrete data structure that is appropriate for storing the characters in the constructor. We'll discuss this (and more!) on Monday.
bst.py (practice only)
I have created a BST folder in our handouts directory. There you can find the beginnings of the binary search tree implementation that we did in class today. I have also included a testBST file that contains some docmod tests. I would strongly suggest trying to get the bst.py code to the point where it passes the tests. It's good practice of both trees and recursion. Getting a handle on this will be a great help for the second phase of the final project which I will be rolling out on Monday.
prefixtree.py (due 4/7, midnight)
I have placed starter code our PrefixTree class in wordgame folder in handouts. You job is to complete the code so that it passes the tests.
graphical word game (due 4/19, midnight)
The last files required for our wordgame have been placed in the wordgame folder. Here's a quick run-down:
wordgrid.py: I have added some new functions related to finding words using a PrefixTree at the bottom of this file. You should copy an paste those new functions into your own version of wordgrid.
lexicon.py: This implements the class to manage our dictionary of words. It takes care of loading words from a file and in addition to building a PrefixTree also handles producing random letters and sequences of letters.
words.txt: This is the file of words that our game will use.
wordgame.py: This file implements the logic for the main game. You will have to fill in the missing functions. It is ESSENTIAL that you do not change the signatures of these functions in any way, as the GUI depends on them.
main.py and akerue.kv: These two files define the GUI interface for the game implemented in kivy. You do not need to modify them in any way. When you are ready to try out your game app, simply run the main.py program.
You should be able to build and test all of the non-graphical components of this application using whatever Python you have on your machine. To run the graphical interface of the final application, you will need to have kivy installed. Kivy is available for Python 2 in the Linux lab. So you can always try out the final app by running it from idle there (or from a command line via "$ python main.py").
Some addtional notes: Here is an example of how you might interactively test your game without using the GUI.
>>> g = WordGame() >>> g.getCurrWord() '' >>> g.getPath()  >>> g.getGridChars() 'EOGOORUACRMIEHCT' >>> g.boardButton((0,0)) >>> g.getPath() [(0, 0)] >>> g.getCurrWord() 'E' >>> g.enterButton() >>> g.getPath()  >>> g.getPlayerWords()  >>> g.boardButton((0,2)) >>> g.boardButton((1,2)) >>> g.boardButton((2,2)) >>> g.getCurrWord() 'GUM' >>> g.enterButton() >>> g.getPlayerWords() ['GUM'] >>>
WINDOWS USERS: if you are trying to install kivy on your
own machines, the instructions at kivy.org seem to work if
you do the "Nightly wheel installation." For most of you the
correct wheel file is the one for python3.5, 32 bit.
In order to make the python pip commands work (steps 1 and 2)
you will need to be working in the folder where your python
is installed, typically something like: