selecting and working with appropriate data type

[lane straatman]

I'm trying to figure out what data type is appropriate to represent a
card in a game. The idea that I thought was going to work was a
struct, foo, with two integer fields and two fields of char arrays:
index cardno description suit
( 1, 1,Two of clubs ,'c')
( 2, 2,Three of clubs ,'c')
( 3, 3,Four of clubs ,'c')
( 4, 4,Five of clubs ,'c')
( 5, 5,Six of clubs ,'c')

[lane straatman]

pete wrote:

lane straatman wrote:

pete wrote:

LS: fishing for hints on representing a poker game

Consider the hand as an array.
Sort the array, and check for equality in consecutive elements.
Paul Hsieh wrote a program that I like,
which fully evaluates poker hands and scores them.

Does Paul's version come up with a number for a hand that would inform
a decision? LS

Yes.

I deleted some unused variables and did very little reformatting.
This is pretty close to what he posted:

[post downloaded but snipped for brevity]

pete

#include <stdio.h>
#define LU_RAND(S) ((S) * 69069 + 362437 & 0xffffffffLU)
int main(void)
{
/** #define LU_RAND_SEED 1124021992
** 1124021815
** 1141904096
** 1141906091
** 1143411367
** 123456789LU */
unsigned long seed;
int i;
seed = 1124021992;
printf("%lu\n", seed);
for (i = 1; i < 1000; ++ i)
{
seed = LU_RAND(seed);
printf("%lu\n", seed);

}
return 0;
}
end source
This prog is heavily snipped from pete's upthread post. He circumvents
a rand() call with the macro, and I've been trying to find cracks in
it, but have only succeeded in finding cracks in my own knowledge of
C. With his choice of 69069, 362437 and mask, he never busts his data
type. Nor can I find a non-randomness mod some smallish number.

I don't understand the mask. If I remove f's, I lose 2 digits on the
number, yet there seems to be an extra f to my thinking. If I add an
f, I get the following warning that doesn't turn out to be true:
warning C4244: '=' : conversion from 'unsigned __int64 ' to 'unsigned
long '. What give's?

I was "certain" that the results for 5 card stud was **way** heavy on
pairs and trips until I took out a deck of cards and got empirical.
For Hold 'Em enthusiasts, you can look at it as the community cards.
You'll be less inclined to pull the trigger with a pocket pair.

Poker is a great way to sharpen up one's syntax. Familiar and hands
on. I've been down the hall at comp.lang.fortr an, using Metcalf, Reid
& Cohen. I've yet to assail interoperabilit y with C, and one reason
for that is that I don't see types I recognize. Are the following
kosher types: int_least32_t , int_fast64_t , long double _Complex ,
_Bool ? LS

[Bill Reid]

lane straatman <gr**********@n etzero.netwrote in message
news:11******** **************@ n67g2000cwd.goo glegroups.com.. .

Bill Reid wrote:

lane straatman <gr**********@n etzero.netwrote in message
news:11******** **************@ 79g2000cws.goog legroups.com...

pete wrote:

LS: fishing for hints on representing a poker game
>

As is usually the case, it turns out he was looking to solve
Fermat's Last Theorum and asked how to add 2+2...

It was only a century back that logicians proclaimed that "arithmetic
teeters."

Math can be pretty wacky...read the history of "probabilit y theory"
and compare it to what we know now for some good laughs, and those
comedians are/were the renowned mathematicians of their day...

Consider the hand as an array.
Sort the array, and check for equality in consecutive elements.
Paul Hsieh wrote a program that I like,
which fully evaluates poker hands and scores them.

This is one that I wrote:

/* BEGIN shuffle.c */

#include <stdio.h>

[main and beyond snipped for brevity]
Thanks all for replies and in particular pete for his generous post.
I'm a mile away from a compiler now, so I can't step through it, but

it

looks as clean as a whistle.
>

Well, as one of my "mentors" on one of my first jobs said, "if it
looks good, it must be good"...

I really do prefer my object-oriented C++ card-playing classes
myself...

What is it that you gain from OO?

The ability to write simulators for new games without re-creating all
the code for "cards", "deck of cards", "card table", "dealer", "players",
etc. Basically, I can just write a new "game" class with some new
"strategy" tables and I'm done...

One thing I want to do is to be able to calculate is how much of a
difference it makes in the odds when a card gets flipped up, which
happens fairly frequently in real life, and on which I have no numeric
handle. A card flipped up during the deal--in Western
Michigan--becomes the burn card. I'm unaware of how universal this
practice is. An upturned burn card would differ from the usual, I
should think.
>

It's just a card that can never be drawn to the community cards or
to a player's hand, so you remove it from the deck remainder that
you evaluate using combinatorial analysis...oh wait, are you writing
a combinatorial analyzer, or a "Monte Carlo" simulator, or
perhaps a simulator that can call in a combinatorial analysis
at any time, or what?

Monte Carlo is the short answer. I'm only able to do combo with pen
and paper. It's nice to have a computer tell you that you've got the
correct answer.

Ah, yes, once again, check the history of "probabilit y theory" and
note it only really "gelled" as the result of empirical studies, which is
greatly aided these days by high-speed computer simulations. Las
Vegas exists because of the laws of probability but the casino owners
didn't (and still largely don't!) know the laws, they only kind of know
"what works" (note that even after Dr. Thorp calculated the "odds"
of a hand of blackjack, they STILL didn't really understand the
game they were offering)...

Of course, if you able to do the calculation with "pen and paper",
you can do it with a computer, but you admit you don't really trust
your math skills. So you want to simulate the game and compile
the statistics to see what really happens. So what you really want
is not a full poker simulator, but a more limited simulator that just
checks the hand completion results after a particular card is "seen".
Be aware that you'll have to run many billions of trials for each
of the possible combinations of your dealt cards and the "seen"
card in order for the varying results to resolve to a statistically-valid
"expectatio n" number.

More than anything though, I like to see a scenario,
say, that you're dealt a pocket pair and see how the bidding might go
given tight/loose players, short/tall stacks and position.

OK, that's a full simulator. You're dealing with a lot more variables
there, and getting into some of the more "intangible/chaotic" aspects of
poker, given that in real life, "tightness" and "looseness" can and do
vary themselves as player "psychology " changes. The "bidding"
itself is dependant on YOUR "tightness" or "looseness" in many
situations.

In addition to biting off more than you can chew coding- and
game theory-wise, you may be asking a question that already
has a better strategic answer, if your goal is just to learn how
to win at poker...

Right now,
I array the cards and "players" on my desk and try to do the odds
analysis.

Of course, you can "see" the other player's cards, which is a tremendous
advantage you only sometimes get in a real game!

In real life, I'm having trouble playing with loose players
on tall stacks in cash games. The burning question there is usually
just when to push all in.

Yeah, those pesky "real-life" players will do it to you every time!
Here's a well-known clue: NOBODY can win in a truly "loose"
game. Here's the (duh!) strategy: DON'T PLAY IN THOSE
GAMES. Problem solved!

Of course, it is also impossible to win in a truly "tight" game
either. The general strategy for winning consistently at poker
thus reduces down to choosing your opponents (ideally,
"loose/scared"), not trying to figure out how to win in games
where nobody has a chance of winning.

---
William Ernest Reid

[pete]

lane straatman wrote:

>
pete wrote:

lane straatman wrote:

>
pete wrote:
LS: fishing for hints on representing a poker game
>
Consider the hand as an array.
Sort the array, and check for equality in consecutive elements.
Paul Hsieh wrote a program that I like,
which fully evaluates poker hands and scores them.

Does Paul's version come up with
a number for a hand that would inform
a decision? LS

Yes.

I deleted some unused variables and did very little reformatting.
This is pretty close to what he posted:

[post downloaded but snipped for brevity]

pete

#include <stdio.h>
#define LU_RAND(S) ((S) * 69069 + 362437 & 0xffffffffLU)
int main(void)
{
/** #define LU_RAND_SEED 1124021992
** 1124021815
** 1141904096
** 1141906091
** 1143411367
** 123456789LU */
unsigned long seed;
int i;
seed = 1124021992;
printf("%lu\n", seed);
for (i = 1; i < 1000; ++ i)
{
seed = LU_RAND(seed);
printf("%lu\n", seed);

}
return 0;
}
end source

This prog is heavily snipped from pete's upthread post.
He circumvents
a rand() call with the macro, and I've been trying to find cracks in
it, but have only succeeded in finding cracks in my own knowledge of
C. With his choice of 69069, 362437 and mask, he never busts his data
type. Nor can I find a non-randomness mod some smallish number.

There are three prng's that I use,
which I call "the fast one", "the good one" and "the standard one"
LU_RAND(S) yields alternating odd and even values,
which is why it's not "the good one".

The stamdard one is in the standard.
The good one is RAND_32LU(S), located here:
http://www.mindspring.com/~pfilandr/...istributions.c

The algorithms are not original ones of mine.
What I've gleaned over the years of reading this newgroup
and comp.programmin g, is that until you become expert in prng's,
it's best to leave the prng algorithms to the experts.
"The good one" is adapted from something posted by
George Marsaglia who I believe is an expert on the topic.

The purpose of the mask, is to keep the results
portable in case of long having more than 32 bits.

Purpose of using the prng's instead of rand(),
is to make the results duplicatable across different C paltforms.

--
pete

[Lane Straatman]

"pete" <pf*****@mindsp ring.comwrote in message
news:45******** **@mindspring.c om...

There are three prng's that I use,
which I call "the fast one", "the good one" and "the standard one"
LU_RAND(S) yields alternating odd and even values,
which is why it's not "the good one".

The stamdard one is in the standard.
The good one is RAND_32LU(S), located here:
http://www.mindspring.com/~pfilandr/...istributions.c

The algorithms are not original ones of mine.
What I've gleaned over the years of reading this newgroup
and comp.programmin g, is that until you become expert in prng's,
it's best to leave the prng algorithms to the experts.
"The good one" is adapted from something posted by
George Marsaglia who I believe is an expert on the topic.

The purpose of the mask, is to keep the results
portable in case of long having more than 32 bits.

Purpose of using the prng's instead of rand(),
is to make the results duplicatable across different C paltforms.

It takes me a bit to play with these, but that will be easier now that I'm
hooked up to the net again.
http://www.mindspring.com/~pfilandr/...istributions.h has
prototypes. LS