Re: ti-83 basic programming / poker

the other day i got thinking about my problem and realized that since
each number represented a different card and suit (1 = As 52 = Kh) I
wouldn't have to write out all the different combinations of hands
within the program. For example a straight would be any combination of
cards that are consecutive with disregard for the suits (if suits are
taken into account that would make it a straight flush). So looking at
the chart below:

A 2 3 4 5 6 7 8 9 10 J Q K
+-------------------------------------------------
S | 1 2 3 4 5 6 7 8 9 10 11 12 13
|
C | 14 15 16 17 18 19 20 21 22 23 24 25 26
|
H | 27 28 29 30 31 32 33 34 35 36 37 38 39
|
D | 40 41 42 43 44 45 46 47 48 49 50 51 52

one can see that a straight flush would consist of any 5 consecutive
numbers between 1 and 13, 14 and 26, 27 and 39, and 40 and 52. so i
could use statements such as if 1_<a_<9 and b = a+1 and c = a+2 and d
= a+3 and e = a+4 then display "straight" if a = 1 or a = 14 or a = 27
or a = 40 and b = a+ 9 and c = a+10 and d = a + 11 and e = a + 12 then
display "royal flush" and so on and so forth for every single hand in
poker. using simple math a = b + c i would be able to cut down the
need for analyzing every single poker hand. i would also have to take
into account that the values for each hole card and community cards can
be used to form a hand which would result in different combinations of
the same formula such as a = b + c, b = a + c, c = a + b, etc.

Arthur J. O'Dwyer wrote:
> On Fri, 28 Oct 2005 jawon81@xxxxxxxxx wrote:
> >
> > hi everyone i am in the process of programming a texas holdem game for
> > the ti-83 graphics calculator. i am using their basic programming
> > language.
>
> Yay! Good for you!
>
> > so far i have been able to randomize the cards and output them to the
> > screen, here is the basic code for what i've been able to accomplish so
> > far:
> >
> > LBL Z:
> > randint(1,52)->a // Hole
> > randint(1,52)->b // Cards
> >
> > randint(1,52)->c
> > randint(1,52)->d // Flop
> > randint(1,52)->e
> > randint(1,52)->f // Turn
> > randint(1,52)->g // Rivers
>
> So far so good. At some point you'll want to get rid of those
> superfluous closing parentheses. :)
>
> > IF a=b or a=c or a=d or a=e or a=f or a=g or
> > b=c or b=d or b=e or b=f or b=g or c=e or c=f
> > or c=g or d=e or d=f or d=g or e=f or e=g or
> > f=g
> > THEN
> > GOTO Z
> > ELSE
>
> Ick! First of all, tangentially, it seems like you're not aware that
>
> IF X:GOTO Z
> is superior to
> IF X:THEN:GOTO Z:END
> for reasons besides simply taking less memory. Executing a GOTO inside a
> block terminated by END will mess with the interpreter's stack; it will
> keep expecting an END to finish the THEN block.
>
> Here's the advice you really wanted, though:
>
> {A,B,C,D,E,F,G->L1
> SortA(L1
> IF (not(min(AList(L1:GOTO Z
>
> where 'AList(' is the "delta List" operation, option 7 under LIST->OPS.
> This code says: Put all seven cards in a list, and sort them in
> ascending order. This puts any duplicate cards next to each other. Then,
> we simply take the differences of adjacent cards; if any of the
> differences are zero, then we have one or more duplicate cards.
>
> But that's really not the way you want to do it, I think. It depends
> on whether you want to allow card-counting or not. If not, your way
> is OK, if tedious --- each deal will consist of seven cards picked
> completely at random from the deck. But if you do, then you need some
> way of remembering which cards have already been dealt.
> The simplest solution, I think, is to code what you'd do in real life
> --- take the deck, shuffle it, and then pick the first seven cards.
> You can do that like this:
>
> seq(I,I,1,52->L1
> rand(52->L2
> SortA(L2,L1
>
> Now L1 contains a random permutation of the integers between 1 and 52.
> Then it's just
>
> L1(1->A
> L1(2->B
> ...
>
> Or you could just forget about A,B,... and use the indices into L1
> directly. Perhaps have a pointer D for "top of deck," like this:
>
> 1->D
> // do a hand of poker
> D+7->D
> IF D>45:THEN
> // reshuffle the deck
> 1->D
> END
>
>
> > if x=1:output(1,1,"As")
>
> Modulo arithmetic is your friend. :)
>
> [...]
> > so now the next step is for me to program the different strengths of
> > the hands also taking into consideration all the different aspects of
> > texas holdem poker.
> >
> > now i could keep on writing the program but it will be very tiresome to
> > program in all the different combinations of winning hands because
> > there are so many different combinations of the 9 different hands in
> > poker. for instance a 5c6c7c8c9c is a straight flush and so is
> > 2c3c4c5c6c. this would probably result in about thousands of line of
> > code and programming this is basic can become very annoying at best.
>
> Well, it's going to involve a certain amount of tedium, because poker is
> a pretty arbitrary game. But you can certainly cut down the work by using
> the techniques I've already demonstrated. For example, to see whether the
> player has a flush showing, it's
>
> 0->T // no flush found yet
> {A,B,C,D,E,F,G->L1
> iPart(L1/13->L1 // compute the suits of the cards
> IF 0=L1(5:1->T
> IF 3=L1(3:1->T
> IF not(T:THEN
> 1/(L1-1.5->L1
> IF -2=L1(5:1->T
> IF 2=L1(3:1->T
> END
> IF T:THEN
> Disp "FLUSH
> ELSE
> Disp "NO FLUSH
> END
>
> This is another reason you might not want to use A,B,C,... to hold card
> values --- you'll want a lot of scratch variables to hold the results of
> these tests.
> For hands such as one pair and straight, you'll need to have the
> variable hold not just 0 or 1, but a number whose magnitude indicates
> the strength of the hand --- two aces beats two jacks, for example. The
> mapping from hands to numbers is obvious in those two cases, but it might
> require some thought for a hand like full house.
>
>
> > hopefully when i get the program working i will be able to add graphics
> > and even make the game networkable between other plays via the cable :D
>
> I'd say skip the graphics. Basic is bad at graphics even for "dumb"
> games like Snake and Skiing, and it's a lost cause when it comes to
> "smart" games like poker. You'll be spending too many cycles on processing
> the hands to worry about drawing things to the graphics screen.
>
>
> Hope this helps. Feel free to post if you get stuck; I like TI-83
> programming. ;)
>
> -Arthur

.

Relevant Pages

  • Re: Another poker probability problem
    ... brute force and calculations. ... Within each straight flush there are ten distinct combinations of three ... cards one can form. ...
    (sci.math)
  • Re: Probability/Math Question for Gary Carson
    ... I was called by the SB who turned over K-J ... Of the five board cards, ... delivered the nut straight. ... My calculation, (which I ...
    (rec.gambling.poker)
  • Re: poker card game revisited (code included)
    ... code now is that it only returns 1 straight which is enough for mere ... cards that represent the highest hand. ... way to look for matches is with a histogram based on the card rank. ... Searching for straights and flushes is much better done by masks. ...
    (comp.lang.python)
  • Re: Things I learned this year ...
    ... an "inside straight" is a set of cards that are missing ... So 2-3-5-6 is missing the 4 to be a straight. ... "Inside flush" doesn't mean anything as far as I can tell (a ...
    (rec.arts.sf.composition)
  • Probability/Math Question for Gary Carson
    ... Of the five board cards, ... delivered the nut straight. ... My calculation, (which I ... probabilities, I dealt 100 hands manually to get an idea of just how ...
    (rec.gambling.poker)