Problem 054

[inhahe]

Problem 54 isn't clear. In Example hand 2, the highest cards are said to be Ace and Queen. In example 4, the highest cards are said to be 9 and 7, even though each hand has Queens. So there are obviously rules for which cards to count when determining the "highest card", and they're not specified.

I could assume that you select only from cards that aren't "used", but that's not consistent either because in some cases they're all "used", and in any case I shouldn't have to assume. Can you tell me what the rules are and/or update the web page? Thx.

[GraemeMcRae]

I think the ambiguity is part of the puzzle. When I solved it, I made lots of reasonable assumptions based on my very limited knowledge of poker. For example, I assumed if both hands are the same "high card", then I would compare the next cards, etc. After comparing all the cards, it's possible that there might be a draw, but the puzzle says there is always a clear winner, so I didn't worry about that. I don't even know if all my wild and crazy assumptions came up in the data, but the point is that I was able to solve the problem by making them.

[inhahe]

crap, i had an ingenious solution that only involves 31 lines of code, but the rules about the highest card completely throw a monkey wrench in that. that's why i was hoping for exact specifications. actually i'll assume it's the highest non-used card if they're not al l used and the highest card if they're all used. that shouldn't add too much complexity.

[inhahe]

oh! duh! the problem was i was assuming they weren't using the Qs for the high card because they were used in the pattern. but they weren't using them just because the highest cards were equal. so that's the only thing i have to do, what you said, use the next highest value if the highest is equal. thanks.

[inhahe]

i solved it. i had to look up the rules of poker on a separate website.

[GraemeMcRae]

Do you know what rule you learned from that other website that enabled you to solve the problem?

[euler]

That's a good point, inhahe. I've updated the page to mention the highest card is the "Highest value card not used in any combination listed below"
http://projecteuler.net/index.php?secti ... lems&id=54
I hope that clarifies it.

[GraemeMcRae]

That's a good point, inhahe. I've updated the page to mention the highest card is the "Highest value card not used in any combination listed below"
http://projecteuler.net/index.php?secti ... lems&id=54
I hope that clarifies it.

I'm not sure that's an improvement. If you classify hands into the 10 categories listed (i.e. High card, Pair, Two pairs, etc.) then "High card" is the name of a category of hand, not a description of one of the cards in a hand.

Although I think example 4 really settles it without the need for any further explanation, what might be needed instead is an explanation of comparing two hands of the same category. You could start off by explaining what a "participating card" is (with only the three-of-a-kind in a full house participating, or else two levels of participation -- whew!). Then, if the highest participating card of one hand has a higher value than the highest participating card of the other hand, then the first hand wins. Otherwise, if the highest participating cards of the two hands are equal, then it goes to the highest (and then second highest, etc.) nonparticipating card to break the tie.

--Graeme

[euler]

I've added a qualifying sentence after the sentence listing the order of the value of the cards:

"If two hands tie then highest cards are compared. If the highest cards tie then the next highest cards are compared, and so on."

With the rest of the text this should remove all ambiguity.

[GraemeMcRae]

You didn't clarify what it means for two hands to "tie". If "tie" means they are in the same category (e.g. both hands have a single pair), then your new clarification is misleading, because a pair of threes beats a pair of twos regardless of the highest card in either hand. I think you need to introduce the concept of "participating card", which is described here as a card that is "part of the combination". However you want to word it. Or else let it go -- example 4 speaks for itself.

[euler]

But a pair of threes does beat a pair of twos. For example, 33654 beats 22AKQ, but 22A43 beats 22KQJ; check out the paragraph on pairs (9. Pair) in the link you provided.

[GraemeMcRae]

I think we're misunderstanding each other. Let's go back to your latest edit on the puzzle page. You said "If two hands tie then highest cards are compared." What do you mean by "tie" in this case?

[euler]

I see what you're saying: if two hands tie then they tie and there isn't a winner. I've rephrased that paragraph and introduced the term "rank" to help clarify:

"If two players have the same ranked hands then the rank made up of the highest value wins; for example, a pair of eights beats a pair of fives (see example 1 below). But if two ranks tie, for example, both players have a pair of queens, then highest cards in each hand are compared (see example 4 below); if the highest cards tie then the next highest cards are compared, and so on."

[GraemeMcRae]

Perfect! (almost...)

A full house three's over twos beats a full house two's over nines. I'm not sure your latest suggestion makes that clear, but it's much better.

[euler]

Actually your example would require five twos in a pack! But I know what you mean...

I would hope that it requires a small amount of extrapolation and the intelligent reader is able to reason in the following way... both hands tie on rank as they both have full house, so we need to consider the highest value card. As a prile beats a pair we need consider the value of each prile. Threes beat twos, so 33322 beats 22299.

But having said that, the aim is to remove all ambiguity, so I've added a variation of this hand as a 5th example.

[Haoest]

Hi,

I've been stuck on this one for a long time. I blame on my work schedule, but it really is how I can not come up with a systematic solution that can compare hands without spaghitti code.

I thought of ordering the hands in a certain way, or mimic how regular expression engines work because in a way it has something to do with states, but those approaches got me nowhere. Can anybody give me some web reference / books that I can read on, or give me some personal insight to solve this problem?


Thank you!!
Hao

[JohnMorris]

Well, the whole point of Project Euler is to solve the problem for yourself, with little or no outside help. If it takes spaghetti code to do that, then go ahead and write the spaghetti code. I guarantee you will learn something as you do it.

I've written some very long and ugly (and shamefully slow) programs for some problems, only to smack myself when I eventually see the elegant answers others have come up with. I bet that's true for 99% of the people here. That's ok - you don't have to write great code - just good enough to get the answer.

The reward will be that you will get access to the problem 54 forum, with a good discussion of methods and algorithms and other solvers' code - and after the thinking and learning you will already have done, the discussion there will be much more meaningful for you.

And always remember that Google is your friend.

Good luck, and keep thinking - it's worth the effort.

[Tommy137]

If you really find a nice solution then share it. I didn't find any

[joshbowman205]

I spent a lot of time optimising this type of thing for a similar problem, got it down to about 300 cpu cycles to evaluate a hand. A suggestion would be that each hand can be given a suitable integer score - essentially the same problem

[dave_the_fish]

Well, it has taken me 20 minutes to realise that the 'T' in 'TD' stands for 10. Doesn't bode too well for this question.