Jon
Matthew Brown wrote:A couple of comments, if you're interested.
1. I don't think your method of identifying a straight flush by adding the suit and card values together works. It can't tell the difference between {AH, KH, QH, JH, 10H} and {AD, KS, QD, JS, 10H}. The 4-of-a-kind method method has a similar problem as well.
2. The following code:
can be entirely replaced by:
See this excel sheet (requires spreadsheet software)
What I am worried about if other combinations can lead to my validation being "hacked" by chance, and, I have posted a separate question in a Math forum, because I'm too busy to read Advanced Algebra in 21 Days
However, I am afraid I made a big mistake, because I am calling static values, which will return a value whether or not the _card (Card class) are held by the Player So for example another combination of cards can lead to the same mathematical result, and, I am not sure whether there is an algebraic formula to determine this or work around this.
At some point I might be adding in some fancy probability statistics, so at that point I would have a thought about how probability fits with my application as well.
On the other hand the code is selectively going through each card, hence, it won't count any cards that are not on the _player's hand, do you agree?
Jon
Matthew Brown wrote:A couple of comments, if you're interested.
} [/code]can be entirely replaced by:
[code=java]for (Card _card : _cardsAtHand) {
_rankCount += _card.ordinal();
} [/code]
In fact, all the switch statements (and you look like you're planning a lot of them) can be removed in a similar way.
Jon
Matthew Brown wrote:Sorry, it's not immediately obvious what your worry about statics is related to.
In case it's useful, here's how I think I'd approach working out what the hand is. The key, I think, is to work out what data structures are most useful, and then pre-process the hand to get it into those structures. I'd be tempted to create two Maps:
Map<Card.Suit, List<Card.Rank>> suitMap;
Map<Card.Rank, List<Card.Suit>> rankMap;
So the first maps the suits held to the numbers in that suit, and the second maps the numbers to the suits they are held in. I'd also make sure the Lists and Maps are sorted (use a TreeMap for the latter).
Once I'd done that, then I'd start checking conditions:
- Flush: Only one entry in suitMap (containing 5 rank values)
- Straight flush: as for Flush, but the difference between the ranks of the highest and lowest is 4 (it's a sorted list, remember) - with an additional bit of cleverness to cope with the Ace being high or low.
- Four of a kind: rankMap contains a list with 4 values in it
- Full house: rankMap contains only two lists, one with 3 values in it
- Straight: rankMap contains 5 lists (one value in each), and the difference between the highest and lowest values is 4 (again, allow for Aces).
etc.
Jon
Matthew Brown wrote:I think an ArrayList (or Set) is fine as the structure to hold the hand in. But you're not limited to only having a single data structure if different ones are useful for different purposes. So first I considered what things about the hand I wanted to be able to find out. To identify four of a kind, full house, pairs etc, what I want is a quick way of finding out how many cards there are with the same rank. A map of rank vs the suits of that rank makes that easier. So I'll build that structure first, then I can reuse it for all those checks. But that's structure is useless for identifying flushes. But invert the map so you have suit mapped to the numbers in that suit, and identifying a flush becomes trivial.
My whole aim here would be keeping the logic as simple as possible. If you find yourself repeating similar logical steps when identifying each hand then the chances are there's a simpler approach.
[Incidentally, all this suggests to me that it might be useful to have a Hand class containing all this logic].
Jon
Did you see how Paul cut 87% off of his electric heat bill with 82 watts of micro heaters? |