Question text is in black, my answers in blue.
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!
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!
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).
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 So, your code in You can then use the reference to Why does
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
Arrays.sort() method, which will make calls to
RankAndFreq.compareTo() method to put the array into
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).
repopulate the array
Hand.cards, this time in the right
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.
So, your code in
You can then use the reference to
RankAndFreqobjects -- 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
this.ranksAndFreqs = new RankAndFreq[cards.length];that creates a new array of
RankAndFreqobjects. 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
new statement. Only primitive data items
automatically exist without being created.
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.
Last modified 26 October 2009
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.
Last modified 26 October 2009