Mod Removes Wiki by Martin Ender
    Post Merged (destination) from meta.codegolf.stackexchange.com/questions/1847/…
    Post Merged (destination) from meta.codegolf.stackexchange.com/questions/336/…
7 deleted 601 characters in body; deleted 500 characters in body
source | link

There seem to be lurking bugs, and I would appreciate it if I/we could bang them out before I go public with this KOTH. The source code for the contest and all the bots I've created is available. I can't prove a bug, but I suspect that Double-Nut (who always doubles-down) wins a little bit too much.

Fixed the bigs which made double-down such an incredibly successful strategy. Basic testing finally appears to produce the expected results while there is a tiny glitch in the printing somewhere.

Should bots have an argument which specifies the number of decks now in play, or should card-counters be forced to guess?None! (no known problems at least)

  • Add a system which counts the number of rounds each non-broke bot has played, and try to generate tables to keep all the remaining bots with the same number of hands played until the tournament length is reached.
  • Add a system which prevents bots from betting more chips than they have or betting negative values.
  • Add a set of defaults to the CLI (default verbosity, population etc)
  • Add verbosity control to the CLI
  • Update and unit-test the CLI to ensure proper function
  • Hunt down the glitch which makes DD print an extra space

5/25 - 1620 - v5 - added an explanation of the betting and card-dealing system, major status update.

5/27 - 1700 - v6 - ready to roll the contest...

There seem to be lurking bugs, and I would appreciate it if I/we could bang them out before I go public with this KOTH. The source code for the contest and all the bots I've created is available. I can't prove a bug, but I suspect that Double-Nut (who always doubles-down) wins a little bit too much.

Fixed the bigs which made double-down such an incredibly successful strategy. Basic testing finally appears to produce the expected results while there is a tiny glitch in the printing somewhere.

Should bots have an argument which specifies the number of decks now in play, or should card-counters be forced to guess?

  • Add a system which counts the number of rounds each non-broke bot has played, and try to generate tables to keep all the remaining bots with the same number of hands played until the tournament length is reached.
  • Add a system which prevents bots from betting more chips than they have or betting negative values.
  • Add a set of defaults to the CLI (default verbosity, population etc)
  • Add verbosity control to the CLI
  • Update and unit-test the CLI to ensure proper function
  • Hunt down the glitch which makes DD print an extra space

5/25 - 1620 - v5 - added an explanation of the betting and card-dealing system, major status update.

None! (no known problems at least)

5/25 - 1620 - v5 - added an explanation of the betting and card-dealing system, major status update.

5/27 - 1700 - v6 - ready to roll the contest...

6 see changelog as usual
source | link
  • Bots play at tables of four (4) competitors and one (1) dealer
  • One (1) shoe is shared by all players and the dealer until it is exhausted, at which point a new randomly shuffled deck will be added and play will continue. The bots ARE NOT (at present) NOTIFIED of the addition of this new deck. [TODO? would make card-counting a LOT harder...]
  • There is a buy-in of 10 per round, and cards are free
  • There is no bet maximum as bets are between the player and the house, yet the bot must have sufficient chips to immediately finance the bet.
  • Perfect/ideal hand has a score of 21
  • All face cards have a value of 10
  • All numeric cards are worth their number
  • Aces are worth 11 or 1. this will be dealt with automatically by the framework, not the bots.
  • Scores in excess of 21 which use an ace as 11 force the ace to reduce in value to 1 scores in excess of 21 which cannot be coerced below the threshold of 21 "bust" the bot
  • The dealer draws until he busts, or excedes a score of 17.
  • The stake is subtracted from chips, so the chips value is the number of credits which are available to the bot for betting.

IssuesDealing and Bot Moves

How to handle decks and seating? Any table-generation system must "fairly" allow bots to contend for the crown, YET it must eliminate bots when the go broke just like in a poker contest. This makes it very difficult to generate "fair" tables.

NOTE: bots play against the House - do table arrangements matter?
YES AND NO: the NUMBER OF ROUNDS matters greatly, equal opportunity to win and all.
TABLE COMPOSITION is irrelevant as bots play against the House 

Should bots have an argument which specifies the number of decks now in play, or should card-counters be forced to guess?

  1. When the game starts, each player is iteratively dealt one card, and has the $10 buy-in fee/minimum bet subtracted from their chips.
  2. Then (in the same order as they were dealt to) each bot is executed as described in the "Programmer's Interface" section and must make a move or stand. Betting is considered a move. NOTE THAT BETTING DOES NOT AFFECT BOTS' ABILITY TO MAKE FURTHER MOVES. It is very possible to bet and then draw a card, and it is possible to draw multiple cards and them bet before standing.

Code Review github

There seem to be lurking bugs, and I would appreciate it if I/we could bang them out before I go public with this KOTH. The source code for the contest and allThere seem to be lurking bugs, and I would appreciate it if I/we could bang them out before I go public with this KOTH. The source code for the contest and all the bots I've created is available. I can't prove a bug, but I suspect that Double-Nut (who always doubles-down) wins a little bit too much.

Fixed the bots I've created is available on this github. I can't prove a bug, but I suspect that Double-Nut (who always doublesbigs which made double-down) wins such an incredibly successful strategy. Basic testing finally appears to produce the expected results while there is a little bit too muchtiny glitch in the printing somewhere.

Issues & ToDo

ThanksShould bots have an argument which specifies the number of decks now in advanceplay, I can't waitor should card-counters be forced to take this one publicguess?

Rmckenzie

  • Add a system which counts the number of rounds each non-broke bot has played, and try to generate tables to keep all the remaining bots with the same number of hands played until the tournament length is reached.
  • Add a system which prevents bots from betting more chips than they have or betting negative values.
  • Add a set of defaults to the CLI (default verbosity, population etc)
  • Add verbosity control to the CLI
  • Update and unit-test the CLI to ensure proper function
  • Hunt down the glitch which makes DD print an extra space

5/25 - 1100 - v4 - added a description of the table and shoe system.

5/25 - 1620 - v5 - added an explanation of the betting and card-dealing system, major status update.

  • Bots play at tables of four (4) competitors and one (1) dealer
  • One (1) shoe is shared by all players until it is exhausted, at which point a new randomly shuffled deck will be added and play will continue. The bots ARE NOT (at present) NOTIFIED of the addition of this new deck. [TODO? would make card-counting a LOT harder...]
  • There is a buy-in of 10 per round, and cards are free
  • There is no bet maximum as bets are between the player and the house, yet the bot must have sufficient chips to immediately finance the bet.
  • Perfect/ideal hand has a score of 21
  • All face cards have a value of 10
  • All numeric cards are worth their number
  • Aces are worth 11 or 1. this will be dealt with automatically by the framework, not the bots.
  • Scores in excess of 21 which use an ace as 11 force the ace to reduce in value to 1 scores in excess of 21 which cannot be coerced below the threshold of 21 "bust" the bot
  • The dealer draws until he busts, or excedes a score of 17.
  • The stake is subtracted from chips, so the chips value is the number of credits which are available to the bot for betting.

Issues

How to handle decks and seating? Any table-generation system must "fairly" allow bots to contend for the crown, YET it must eliminate bots when the go broke just like in a poker contest. This makes it very difficult to generate "fair" tables.

NOTE: bots play against the House - do table arrangements matter?
YES AND NO: the NUMBER OF ROUNDS matters greatly, equal opportunity to win and all.
TABLE COMPOSITION is irrelevant as bots play against the House 

Should bots have an argument which specifies the number of decks now in play, or should card-counters be forced to guess?

Code Review

There seem to be lurking bugs, and I would appreciate it if I/we could bang them out before I go public with this KOTH. The source code for the contest and all the bots I've created is available on this github. I can't prove a bug, but I suspect that Double-Nut (who always doubles-down) wins a little bit too much.

Thanks in advance, I can't wait to take this one public

Rmckenzie

5/25 - 1100 - v4 - added a description of the table and shoe system.

  • Bots play at tables of four (4) competitors and one (1) dealer
  • One (1) shoe is shared by all players and the dealer until it is exhausted, at which point a new randomly shuffled deck will be added and play will continue. The bots ARE NOT (at present) NOTIFIED of the addition of this new deck. [TODO? would make card-counting a LOT harder...]
  • There is a buy-in of 10 per round, and cards are free
  • There is no bet maximum as bets are between the player and the house, yet the bot must have sufficient chips to immediately finance the bet.
  • Perfect/ideal hand has a score of 21
  • All face cards have a value of 10
  • All numeric cards are worth their number
  • Aces are worth 11 or 1. this will be dealt with automatically by the framework, not the bots.
  • Scores in excess of 21 which use an ace as 11 force the ace to reduce in value to 1 scores in excess of 21 which cannot be coerced below the threshold of 21 "bust" the bot
  • The dealer draws until he busts, or excedes a score of 17.
  • The stake is subtracted from chips, so the chips value is the number of credits which are available to the bot for betting.

Dealing and Bot Moves

  1. When the game starts, each player is iteratively dealt one card, and has the $10 buy-in fee/minimum bet subtracted from their chips.
  2. Then (in the same order as they were dealt to) each bot is executed as described in the "Programmer's Interface" section and must make a move or stand. Betting is considered a move. NOTE THAT BETTING DOES NOT AFFECT BOTS' ABILITY TO MAKE FURTHER MOVES. It is very possible to bet and then draw a card, and it is possible to draw multiple cards and them bet before standing.

Code Review github

There seem to be lurking bugs, and I would appreciate it if I/we could bang them out before I go public with this KOTH. The source code for the contest and all the bots I've created is available. I can't prove a bug, but I suspect that Double-Nut (who always doubles-down) wins a little bit too much.

Fixed the bigs which made double-down such an incredibly successful strategy. Basic testing finally appears to produce the expected results while there is a tiny glitch in the printing somewhere.

Issues & ToDo

Should bots have an argument which specifies the number of decks now in play, or should card-counters be forced to guess?

  • Add a system which counts the number of rounds each non-broke bot has played, and try to generate tables to keep all the remaining bots with the same number of hands played until the tournament length is reached.
  • Add a system which prevents bots from betting more chips than they have or betting negative values.
  • Add a set of defaults to the CLI (default verbosity, population etc)
  • Add verbosity control to the CLI
  • Update and unit-test the CLI to ensure proper function
  • Hunt down the glitch which makes DD print an extra space

5/25 - 1100 - v4 - added a description of the table and shoe system.

5/25 - 1620 - v5 - added an explanation of the betting and card-dealing system, major status update.

5 forgot to describe shoes and the visible-cards arg
source | link
  • perfectBots play at tables of four (4) competitors and one (1) dealer
  • One (1) shoe is shared by all players until it is exhausted, at which point a new randomly shuffled deck will be added and play will continue. The bots ARE NOT (at present) NOTIFIED of the addition of this new deck. [TODO? would make card-counting a LOT harder...]
  • There is a buy-in of 10 per round, and cards are free
  • There is no bet maximum as bets are between the player and the house, yet the bot must have sufficient chips to immediately finance the bet.
  • Perfect/ideal hand has a score of 21
  • allAll face cards have a value of 10
  • allAll numeric cards are worth their number
  • acesAces are worth 11 or 1. this will be dealt with automatically by the framework, not the bots.
  • scoresScores in excess of 21 which use an ace as 11 force the ace to reduce in value to 1 scores in excess of 21 which cannot be coerced below the threshold of 21 "bust" the bot
  • theThe dealer draws until he busts, or excedes a score of 17.
  • theThe stake is subtracted from chips, so the chips value is the number of credits which are avalibleavailable to the bot for betting.

is the addition of betting too much? Betting implemented successfully.

How to handle decks and seating? Any table-generation system must "fairly" allow bots to contend for the crown, YET it must eliminate bots when the go broke just like in a poker contest. This makes it very difficult to generate "fair" tables.

Should bots have an argument which specifies the number of decks now in play, or should card-counters be forced to guess?

#   DOCUMENTATION
#       INPUT SPECIFICATION
#          $ ./foo.bar <hand-score> <hand> <visible cards> <stake> <chips>
#          <hand-score>     is the present integer value of the player's hand.
#          <hand>           is a space-free string of the characters [1-9],A,J,Q,K
#          <visible cards>  every dealt card on the table. when new shoes are brought
#                           into play, cards drawn therefrom are simply added to this list
#                           !!! THE LIST IS CLEARED AT THE END OF HANDS, NOT SHOES !!!
#          <stake>          the  number of chips which the bot has bet this hand
#          <chips>          the number of chips which the bot has
#       SAMPLE INPUT
#          $ ./foo.bar 21 KJA KQKJA3592A 25 145
#
#       OUTPUT SPECIFICATION
#          "H"|"S"|"D"|"B"  (no quotes in output)
#          "H"              HIT - deal a card
#          "S"              STAND - the dealer's turn
#          "D"              DOUBLEDOWN - double the bet, take one card. FIRST MOVE ONLY
#          "B 15"           BET - raises the bot's stakes by $15.

5/25 - 0920 - v3 - updated the test case to match the input specification. Added the rules for the dealer.

5/25 - 1100 - v4 - added a description of the table and shoe system.

  • perfect/ideal hand has a score of 21
  • all face cards have a value of 10
  • all numeric cards are worth their number
  • aces are worth 11 or 1. this will be dealt with automatically by the framework, not the bots.
  • scores in excess of 21 which use an ace as 11 force the ace to reduce in value to 1 scores in excess of 21 which cannot be coerced below the threshold of 21 "bust" the bot
  • the dealer draws until he busts, or excedes a score of 17.
  • the stake is subtracted from chips, so the chips value is the number of credits which are avalible to the bot for betting.

is the addition of betting too much? Betting implemented successfully.

How to handle decks and seating? Any table-generation system must "fairly" allow bots to contend for the crown, YET it must eliminate bots when the go broke just like in a poker contest. This makes it very difficult to generate "fair" tables.

#   DOCUMENTATION
#       INPUT SPECIFICATION
#          $ ./foo.bar <hand-score> <hand> <visible cards> <stake> <chips>
#          <hand-score>     is the present integer value of the player's hand.
#          <hand>           is a space-free string of the characters [1-9],A,J,Q,K
#          <visible cards>  every dealt card on the table
#          <stake>          the  number of chips which the bot has bet this hand
#          <chips>          the number of chips which the bot has
#       SAMPLE INPUT
#          $ ./foo.bar 21 KJA KQKJA3592A 25 145
#
#       OUTPUT SPECIFICATION
#          "H"|"S"|"D"|"B"  (no quotes in output)
#          "H"              HIT - deal a card
#          "S"              STAND - the dealer's turn
#          "D"              DOUBLEDOWN - double the bet, take one card. FIRST MOVE ONLY
#          "B 15"           BET - raises the bot's stakes by $15.

5/25 - 0920 - v3 - updated the test case to match the input specification. Added the rules for the dealer.

  • Bots play at tables of four (4) competitors and one (1) dealer
  • One (1) shoe is shared by all players until it is exhausted, at which point a new randomly shuffled deck will be added and play will continue. The bots ARE NOT (at present) NOTIFIED of the addition of this new deck. [TODO? would make card-counting a LOT harder...]
  • There is a buy-in of 10 per round, and cards are free
  • There is no bet maximum as bets are between the player and the house, yet the bot must have sufficient chips to immediately finance the bet.
  • Perfect/ideal hand has a score of 21
  • All face cards have a value of 10
  • All numeric cards are worth their number
  • Aces are worth 11 or 1. this will be dealt with automatically by the framework, not the bots.
  • Scores in excess of 21 which use an ace as 11 force the ace to reduce in value to 1 scores in excess of 21 which cannot be coerced below the threshold of 21 "bust" the bot
  • The dealer draws until he busts, or excedes a score of 17.
  • The stake is subtracted from chips, so the chips value is the number of credits which are available to the bot for betting.

How to handle decks and seating? Any table-generation system must "fairly" allow bots to contend for the crown, YET it must eliminate bots when the go broke just like in a poker contest. This makes it very difficult to generate "fair" tables.

Should bots have an argument which specifies the number of decks now in play, or should card-counters be forced to guess?

#   DOCUMENTATION
#       INPUT SPECIFICATION
#          $ ./foo.bar <hand-score> <hand> <visible cards> <stake> <chips>
#          <hand-score>     is the present integer value of the player's hand.
#          <hand>           is a space-free string of the characters [1-9],A,J,Q,K
#          <visible cards>  every dealt card on the table. when new shoes are brought
#                           into play, cards drawn therefrom are simply added to this list
#                           !!! THE LIST IS CLEARED AT THE END OF HANDS, NOT SHOES !!!
#          <stake>          the  number of chips which the bot has bet this hand
#          <chips>          the number of chips which the bot has
#       SAMPLE INPUT
#          $ ./foo.bar 21 KJA KQKJA3592A 25 145
#
#       OUTPUT SPECIFICATION
#          "H"|"S"|"D"|"B"  (no quotes in output)
#          "H"              HIT - deal a card
#          "S"              STAND - the dealer's turn
#          "D"              DOUBLEDOWN - double the bet, take one card. FIRST MOVE ONLY
#          "B 15"           BET - raises the bot's stakes by $15.

5/25 - 0920 - v3 - updated the test case to match the input specification. Added the rules for the dealer.

5/25 - 1100 - v4 - added a description of the table and shoe system.

4 m0ar updates
source | link
3 update
source | link
2 just crap. see version history
source | link
1
source | link
    Post Made Community Wiki by arrdem