1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
|
The second part of this course's poker project is to write
test cases for what you will do in the next course.
In particular, one of the things you will do in your
project in Course 3 is write the code to evaluate
which poker hand wins between two complete hands.
This involves writing all the code to figure out
what kind of hand (straight flush, full house, etc.)
is in a hand, and which 5 cards ultimately make it up.
For example, if one hand is
0c 0s 8s 7d 6d 6s 5c
and the other is
Js 0s 8s 7d 6s 5c 4c
your code in the next course will figure out that
the first hand has two pairs (10s and 6s) with an 8
as the tie-breaking card (called the "kicker"),
and that the second hand has a straight (8 7 6 5 4).
The straight beats the two pairs, so hand 2 wins.
We have provided you with test-eval, which reads
a file containing lines with one pair of hands
on each line and prints out the details of evaluating
that hand. Each line has one hand, a semi-colon,
then the other hand, so the input for the above would
be:
0c 0s 8s 7d 6d 6s 5c; Js 0s 8s 7d 6s 5c 4c
We have put this in example.txt. If you run
./test-eval example.txt
Then you will get the following output:
Hand 1:
--------
0c 0s 8s 7d 6d 6s 5c
- No flush
- The most of a kind is 2 of a kind (at index 0 / value 0)
- Secondary pair at index 4 (value 6)
- evaluate_hand's ranking: TWO_PAIR
- 5 cards used for hand: 0c 0s 6d 6s 8s
Hand 2:
--------
Js 0s 8s 7d 6s 5c 4c
- No flush
- Straight at index 2
- The most of a kind is 1 of a kind (at index 0 / value J)
- No secondary pair
- evaluate_hand's ranking: STRAIGHT
- 5 cards used for hand: 8s 7d 6s 5c 4c
Comparison :
--------------
Hand 2 wins!
============================
You can see that for each hand, this program not only prints
the overall ranking (STRAIGHT, TWO_PAIR, etc), but also the
results of various parts of the evaluation that went into
the decision: Was there a flush? Was there a straight (if
so, where?) How many of a kind were there? etc.
As with other testing assignments, we have written
some broken implementations and placed them in
/usr/local/l2p/poker/
Your goal is to write testcases in tests.txt
that test this problem sufficiently to identify
the problem in each broken implementation we provided.
You can use the run_all.sh script that we provided
to run your test cases against all implementations.
Here are some hints:
====================
- Straights are tricky. Think about various ways that a programmer
might mess up in finding a straight. These problems could include
both figuring out if there is a straight as well as copying out the
cards that make up the straight (or straight flush).
There could even be an off-by-one bug in where to look for a straight
in the hand ("count from 0 to the number of cards in the hand minus
[something], call it i. Check if a straight starts at position i"
In such an algorithm, [something] could be off by one)
- Think about ways in which a programmer might mis-think about what
they need to do. For example, one might think you can check for a
straight flush by checking for a straight AND a flush, but that is
not correct (with more than 5 cards, you could have some that are a
straight but others of the same suit).
- Be sure to just provide simple coverage of the basic cases (each
type of hand outcome, etc).
- The suits are numbers, and can be iterated across )where do you
think we iterate over all the suits?). What if we counted wrong
when iterating over the suits?
- Two pairs have some subtle cases in terms of selecting the right 5
cards for the final hand. Remember from the reading that the way
tie breaking works requires the final 5 card hand to be ordered:
(larger pair) (smaller pair) (tiebreaker)
- Think about everywhere the programer could be off-by-one.
This might include such things as counting through all the
positions in the hand (either missing the start or the end),
or being off-by-one in how many cards are required
for a particular hand (e.g., only requiring 4
cards meet a particular condition instead of 5).
- Note that you may be able to 'game' your way into passing all
the tests locally, but if you do this you won't actually pass the
assignment. The only way to pass is to provide good tests.
- Note additionally that you do not need to use invalid cards
in your tests.
|
