Not another luck-based contest! :O

Alright, I couldn't help but feel a little... er? what's up?

I only started doing the contests with the crossword one. That one was probably the hardest one I've seen so far here, but it was also, in my opinion, the most rewarding.

I don't want to diss this contest too much, but last time I played poker, luck had too much to do for my taste!

I would've preferred blackjack!
The only problem w/ blackjack would be there are already numerous counting strategies, but I feel that blackjack involves more logic than poker.

Right now, the poker script seems to be 80% work involving the scoring of your current hand!

I dunno, perhaps we'll see a script that does some intense optimization.

I'll still do the contest though; I really want that Zend T-shirt!

How is the contest based on luck? Everyone is playing with the same decks! The only factor in who wins is who's script makes better choices. I just don't see where luck is involved.

Luck does have something to do with it. Even though everyone is playing with the same decks, the outcome and the difference between a "good" decision and a "bad" decision is based on probabilities.

Example. If a person could choose to discard cards in an attempt for a royal flush. Now you have the smallest probability of getting this, however, if the cards are in just the right order you could get it. Whereas someone else who logically played with the percentages, would not get it. Also depending on how many cards you discard each hand, the hands for each person are effectively different each time.

So even if you play the percentages perfectly in this game, you could still lose. There is a reason it is called gambling - it is based on luck. If we were to play with maybe a million input files, then the people who got the percentages right would be more likely to win, this is because probabilities are more accurate with an increased sample size. Anyways, sounds like a fun contest and good luck too all!

Is the algorithm going to be based, in your testing, on a set deck of cards or on a set of cards that our program's generate. If each program uses exactly the same set of cards for testing, then that will should test accurately the quality of the algorithm and not be based on luck at all.

I agree that there is luck involved with the entire game of poker. So yes, there is a bit of luck involved here. But, not nearly as much as hoping a teleporter gets you closest to the flag. Logic comes in to play here in a big way....

shots47s, yes all scripts are going to play with the same cards....

I admit it's not as luck-based as CTF; ah, I just personally don't like Poker as much

I dunno, what I'm getting at is that I would prefer a project-type contest, such as the crossword one, or an obfuscation engine. I would even prefer a board game, such as chess...

This game has a much bigger random factor than the ctf game. It doesn't matter how good your logic in this game because potentially you will make the riight moves every time but the card order will reward someone who took one card too few or one too many earlier in the progression.

In CTF you could measure the outcome of the opponents teleport and compare it to your own and decide on an alternative strategy based upon that. There is nothing you can do in this one if the cards are in a particular order that rewards poor decisions made earlier.

I think we might be better served by having groups of 9 cards followed by XX in every tenth position. This way everyone gets the same deal every time and some of the randomness is taken out. Even with this method if the following hand being dealt a bad algorithm could clean up.
AS, AC, AD, JH, JC, KC, QC, TC, 8D
a smart decision would be to keep the full house but a bad one might come up with a royal flush in this instance. This is just an example but the point is no matter how good your code there is a significant chance you will fall prey to the luck of the cards. In CTF you could at least try and shoot the opponent who got lucky and landed near your flag.

B

Cool! The new name of the contest is:

PHP Luck Contest

LOL... ah, baker again

In any case, there is *some* element of luck; well, I guess almost everything does. I just felt that we should try something that minimizes luck as much as possible (such as the examples I gave above), given that we just had that CTF contest.

Well, unfortunately I can't please everyone all the time. I have been considering a chess game where scripts compete and will probably do it soon....

Matt, hopefully, you'll choose a chess-like game rather than normal chess. Let me suggest anti-chess: the object is to lose by forcing your oppenent to checkmate you.

Baker again? <sigh> why's it gotta be like that?

Lest there be some confusion I was a big fan of the CTF game and I think it was and is one of the better ideas for a coding contest like this. I wasn't trying to slam on anyone about the card game either, I was just pointing out that it was very possible that making a mistake could help you win the card game. I don't believe this is very likely and I honestly believe that if you run enough cards through this script the luck factor gets increasingly smaller. The card algorithm involves no luck at all and there is a mathematically correct solution to this problem that would return the highest possible score every time if you ran several million cards through it. My point was just that based upon a statistically small sample (5 decks) it was very conceivable that a bad algorithm could win.

B
P.S. just in case my blunt nature makes it appear I'm complaining let me state I think every contest Matt runs is an outstanding opportunity and a wonderful resource for the PHP community. I hardly ever do anything with flat files (everything I code in PHP is straight data manipulation or database driven) so just playing around with the CTF script taught me a bucnh of PHP that I have never used.

shucks, I was really hoping that luck wasn't going to be a big deal in this contest. But here's what I did:

I wrote up two algorithms for this, one obviously inferior to the other one. Then I ran them against the same randomly-generated input 100 times. The "obviously inferior" algorithm was able to pull out 34 victories. Neither algorithm is optimal, but given this information, I would be tempted just to submit the inferior algorithm since it is 60% less code and is sure to win in a tiebreaker. Of course, I'll be following this to its logical conclusion (the "optimal" algorithm) but I am less certain about the dominance of an optimal algorithm than I was before.