Poker, and my Inner Geek
So my new fond interest in the game of Poker has driven me to buy some decks of cards. Having the decks around has gotten me into the habbit of shuffling them (bridge style mostly) in my spare time. This is mainly because I have lots of nervous energy and I also have an active hands fixation. If I wasn't shuffling the cards I'd be destroying paper clips or something similar.
Well last night my inner geek got an idea and ran with it. What was the idea? Get ready for this. Writing a java class to model a deck of cards. Hahaha. Cam't get much nerdier than that. Right now I have anywhere from zero to nothing in terms of obligations. I can do whatever I want, whenever. No classes, no tests, no job. And what do I keep myself up doing until 8am? Writing java code.
Oh well. It was fun. And for the geeks out there, I'll let you know how I'm doing. So far I have a class to model the cards. Real simple just two fields. One for the Suit and one for the rank. Then I have the beast. The Deck class. It has a constructor that basically creates a new, ordered, out of the wrapper deck. (I'm going for realism here.) Then I added a bridge method. It currently performs a 100% perfect bridge (or several if you give it a number.) The problem of course with this is that it yield predictable results. In fact, I'm beginning to think that even an infite number of bridges won't iterate through all possible deck configurations.
But fear not. Because I'm sure with a little patience I can add in the human imperfections that acutally make bridging an efficient way to shuffle. ( I know many of you are thinking it would be far easier to simply randomize the deck, but for some reason I'm fixated with having the computer mimic the way its really done, as closely as possible.)
Now after some thought I've concluded that there are two main areas where humans fail at perfect bridging. The first is the initial cutting of the deck. In a "perfect" bridge the deck is cut precisly in the middle. I'd guess that in over 95% of real world bridging, the deck isn't split 26/26. So randomizing the cut point in the deck (purhaps within a range since humans are usually close to cutting the deck in the middle) is something to work on.
The next concept of perfect bridging that humans mess up is that reintegration of the two piles of cards into one deck. In my current computer model the deck is reassembled by alternately taking a card from each pile. In real bridging, many times more than one card in a row from each pile is added. Determining the details for this concept I believe will be far harder than humanizing the cutting concept. But I'm sure I'll get it. Maybe ask some friends for help. There is a veritable gold mine of willing Computer Science majors at WPI who would drop most of what they are doing to help me. Then there's Mike James. He loves this kinda stuff.
The best part...I can't wait until I explain this to Mary. If I know her at all, she'll go along with it and even if she doesn't get it, she'll think nice things about me. I hope I hope.
Well last night my inner geek got an idea and ran with it. What was the idea? Get ready for this. Writing a java class to model a deck of cards. Hahaha. Cam't get much nerdier than that. Right now I have anywhere from zero to nothing in terms of obligations. I can do whatever I want, whenever. No classes, no tests, no job. And what do I keep myself up doing until 8am? Writing java code.
Oh well. It was fun. And for the geeks out there, I'll let you know how I'm doing. So far I have a class to model the cards. Real simple just two fields. One for the Suit and one for the rank. Then I have the beast. The Deck class. It has a constructor that basically creates a new, ordered, out of the wrapper deck. (I'm going for realism here.) Then I added a bridge method. It currently performs a 100% perfect bridge (or several if you give it a number.) The problem of course with this is that it yield predictable results. In fact, I'm beginning to think that even an infite number of bridges won't iterate through all possible deck configurations.
But fear not. Because I'm sure with a little patience I can add in the human imperfections that acutally make bridging an efficient way to shuffle. ( I know many of you are thinking it would be far easier to simply randomize the deck, but for some reason I'm fixated with having the computer mimic the way its really done, as closely as possible.)
Now after some thought I've concluded that there are two main areas where humans fail at perfect bridging. The first is the initial cutting of the deck. In a "perfect" bridge the deck is cut precisly in the middle. I'd guess that in over 95% of real world bridging, the deck isn't split 26/26. So randomizing the cut point in the deck (purhaps within a range since humans are usually close to cutting the deck in the middle) is something to work on.
The next concept of perfect bridging that humans mess up is that reintegration of the two piles of cards into one deck. In my current computer model the deck is reassembled by alternately taking a card from each pile. In real bridging, many times more than one card in a row from each pile is added. Determining the details for this concept I believe will be far harder than humanizing the cutting concept. But I'm sure I'll get it. Maybe ask some friends for help. There is a veritable gold mine of willing Computer Science majors at WPI who would drop most of what they are doing to help me. Then there's Mike James. He loves this kinda stuff.
The best part...I can't wait until I explain this to Mary. If I know her at all, she'll go along with it and even if she doesn't get it, she'll think nice things about me. I hope I hope.
2 Comments:
At 10:02 AM,
Anonymous said…
During the bridge shuffle you could randomize the number of cards contributed from both piles each "snap."
So instead of "1, then 1, then 1",
it's more "like 3, then 5, then 1, then........ 2!"
I bet if you measured real people shuffling, you'ld find that the number of cards from each pile, each snap, follows an exponential (pareto) distribution. So the probability of getting 1 card per snap is higher than 5 cards (and exponentially more so.)
At 1:22 AM,
Mike Schenck said…
I dig it. I had thought to simply set up a range, from 1 to some relatively close number and have the computer randomly pick a number in that range to represent how many cards from each pile should be "contributed" for each "snap" as you put it, but you're right, the pattern of variation in the number of cards contributed could be better represented than simply randomness.
While that is quite a bit more work, it certainly fits the motto of this whole thing, that being mimic a human as best you can.
Unfortunately I've gone head-first into my MQP, so any spare geek-like tendencies are usually routed towards my PIC code compiler.
Post a Comment
<< Home