# Questions and Answers on Programming Project #2

#### Project #2 is due electronically by 11:59 p.m., Monday 26 October 2009

Question text is in black, my answers in blue.

• Question P2.1, posted 23 October: I don't understand how you got the figures in the assignment description of part 3 of the project. When you compute the total number of possible values for the hidden community cards, you say (51-2k-2d choose 1), (50-2k-2d choose 2), and (47-2k-2d choose 5). I think it should be (52-2k-2d choose 5) for five hidden cards, (49-2k-2d choose 2) for two hidden cards, and (48-2k-2d choose 1) for one hidden card. Could you please clarify?

You don't understand my figures because they are wrong, and yours are right! With five hidden cards, for example, the hidden cards could be from any of the 52 cards in the deck except for the 2k+2d that are in the players' hands. With two hidden cards, they also can't be the three exposed community cards, so there are 49-2k-2d possibilities, and it's (48-2k-2d choose 1) for one hidden card as you say.

It was my mistake, which Brandon copied from a too-hasty email. I counted the hidden community cards to subtract instead of the exposed ones. Sorry, and thanks very much for spotting the mistake!

• Question P2.2, posted 25 October: In part 2, is the method `map (source, target)` supposed to put its result into the array `target`? And should this array be empty before passing into the method?

Yes, that's correct: `target` will contain a subset of the objects in `source`, and you can assume that before the method runs `target` is an empty array of size at least k, or at least an array of things that you don't mind being overwritten).

• Question P2.3, posted 25 October: In the method `RandAndFreq.compareTo()`, what are we comparing> Other to what else?

You want to compute the shape of a hand to keep track of the frequency of each rank in the hand. The `RankAndFreq` class stores the rank and frequency of a card. One way to do this is to populate a `RankAndFreq[]` array with cards from the hand, and sort it using Java's `Arrays.sort()` method, which will make calls to the `RankAndFreq.compareTo()` method to put the array into ascending order.

So, your code in `RankAndFreq.compareTo()` should return -1, 1, or 0 such that sorting in ascending order places cards with the highest frequency first, breaking ties between frequency by rank, and breaking ties between ranks arbitrarily (by returning 0).

You can then use the reference to `RankAndFreq.card` to repopulate the array `Hand.cards[]`, this time in the right sorted order.

Why does `RankAndFreq` store both the rank and the card? Note that if we ignore straights, then aces always count as the highest rank. So for aces `Card.getRank` is 1, but `RankAndFreq.rank` is 14 to make the sorting work.

• Question P2.4, posted 25 October: I'm still not clear on how to compare two `RankAndFreq` objects -- does one have to have either a higher frequency or a higher rank that the other, or does the rank only matter if the frequency is the same?

The rank only matters if the frequency is the same -- this is what is means for rank to be "a tie-breaker". Here's an example. Suppose that the five cards in the hand are 4S, 5D, 6S, 5C, and 4C. The five `RankAndFreq` objects, with frequency written first in each object, are (2,4), (2,5), (1,6), (2,5), and (2,4). We sort these by frequency, with rank as a tie breaker, and the new order is (2,5), (2,5), (2,4), (2,4), (1,6). This tells us that the hand is two pair, fives and fours, with the fifth card a six.

• Question P2.5, posted 25 October: In the hand class, there's a line `this.ranksAndFreqs = new RankAndFreq[cards.length];` that creates a new array of `RankAndFreq` objects. Does it create the objects themselves, or just the array?

Just the array -- the entries of the array are `null` until or unless you put objects there. A good rule to remember in Java is that every object must be created at some point with a `new` statement. Only primitive data items automatically exist without being created.

• Question P2.6, posted 26 October: What's this about bugs in the code given us?

Some students have discovered some bugs in our code for parts of the project. The less serious one is that Deal.java doesn't account for the discarded cards by making sure they don't occur in the hidden cards. In this case you don't actually have to worry because the testing program uses the same bad code -- there is also new code up on the edlab site. The more serious error is that the compare function in Hand5 sometimes gets the comparison of a flush to a full-house wrong. The main effect of this is that you can get bad test results for perfectly good code.

We're sorry this came up so late, too late for us to really fix things. Just do the best you can (don't worry too hard about a bad test if you think it might come from one of these bugs) and we will do the best we can to grade what you've done, with appropriate understanding for problems caused by the bugs.