-
Notifications
You must be signed in to change notification settings - Fork 0
/
TODO
145 lines (126 loc) · 5.05 KB
/
TODO
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
TODO list:
compute 5-card, 6-card charlie variations
to calculate accurately, state must also encode length of hand
crazy variation:
re-double: double-after-double
when to do this? A-x vs. 6
payoff?
standard analysis:
add variance analysis
analyze Blackjack Switch
when to switch (tables)
BUGS: (run out of cards?)
Dealer plays...
deck_state.cc:120: failed assertion `cards[r]'
Abort
I think this happens when drawing randomly
from the deck when a hole card has been reserved, but not counted.
We need to adjust for the removed hole-card so that it is not
removed twice by accident. Thus there are hidden odds.
Now fixed: Random selection happens accounting for the
removed hole card.
analysis:
impact of using a fixed (basic) strategy in different count situations
imperfections of strategies (betting correlation)
instead of infinite deck, compute finite deck edges (without replacement)
could do on-demand exact calculation as each situation
comes up, instead of for every dealer reveal card,
and every player hand.
Exact odds per situation could be computed using recursion/probability.
Recursion could also be limited based on cumulative probability
falling below tolerance (e.g. 1e-4).
Computing this is taxing --
probability-annotated decision/outcome tree.
post-peek probability (Bayes' Formula):
after checking dealer hole card, there is knowledge about
the hole card, and thus the odds of drawing from the
remaining deck should be appropriately adjusted.
Each card remaining in deck has an increased likelihood
of drawing the card that is ruled out by peeking.
Say there are 13 cards remaining, one of each card,
and one is chosen aside to be the hole card,
and it is known that the hole card is NOT a T,J,Q,K.
Before peeking, the odds of drawing a 10 next was 4/13.
After peeking for 10, there is an equal probability of any non-10
card being the hole card: 1/(13-4) = 1/9. (Generally, N_k/(N-N_10))
The probability of drawing an A (or any non-10 card) next is:
8/9 * 1/12 +1/9 * 0/12 = 2/27.
1/12 comes from 1/(N-1).
The post-peek probability of drawing a 10 next is:
N_10/(N-1) = 4/12 = 1/3.
The sum probability = 9 *2/27 +1/3 = 2/3 +1/3 = 1
Generalized, the post-peek-10 probability of drawing a card k (not 10):
p(hole=k) *p(next=k|hole=k) +p(hole!=k) *p(next=k|hole!=k)
N_k/(N-N_10) * (N_k-1)/(N-1) + (N-N_10-N_k)/(N-N_10) *N_k/(N-1) =
(N_k^2 -N_k + N*N_k -N_k^2 -N_k*N_10)/(N-1)(N-N_10) =
(N -N_10 -1)*N_k/(N-1)(N-N_10)
Added to chapter basic-strategy:peeking.
permissible actions table (action_masks):
different variations may restrict player options for certain hands,
such as double-on-10,11-only,
allow surrender against 10,A only.
Maintain two tables to represent such restrictions,
and for calculations, take the initial permissible actions
as the intersection (bitwise-AND) of the two action masks.
This will not cover everything. Splits are considered separately.
even-money offer on 6:5 blackjack?
rare, but if offered, should *always* be taken
side-bet analysis:
seen in the wild: 6-7-8, paired hand bonus, straight,
flush, 3-of-a-kind.
Typically, never favorable to play these side bets,
but with counting, may actually become favorable!
card randomization:
alternatively, std::shuffle entire sequence up front
this avoids repeated call to RNG,
but makes it difficult to edit the deck.
simulator/analyzer:
I/O: option to read raw character w/o hitting return (ncurses UI)
logging
track statistics
preset options for rules
save/restore state/accounts
define/use API for hooking up custom strategies
define/use API for hooking up different UIs (stdio, ncurses)
factor out current (CLI) interface into libbj-cli
add robot players: play styles [perfect, basic, near-perfect, n00b]
option for infinite deck (replace every card)
almost the same as continuous shuffle
options:
show overall edge given exact count (accumulate)
support different counting schemes besides hi-lo
silent auto-play option for simulations (speed)
betting: auto-change bet amount according to conditions
based on true count or true edge.
set betting granularity.
struct history {
to track every situation and decision?
situations to review? bookmark as a player-choice option
auto-save "wrong" decisions
replay bookmark situations
bookmark insurance queries
quantify how wrong is wrong using edges, score
command: bookmarks-explain, show all solutions
}
commands:
play-option::TMI: too much information
compare basic vs. dynamic strategy
auto-play-until-count (falls below, based on true-count)
command-line options:
paths to search for config/save/load files?
test cases:
using basic vs. dynamic strategy
sensitivity analysis of dynamic strategy and edges
also repeat sensitivity analysis for using only basic-strategy
library:
export interfaces to: python, octave, guile, etc...
using swig
needs well-defined API
paper:
write an academic paper on results
second-order covariant sensitivity analysis
discuss betting strategies, Kelly criterion
betting correlation (efficiency of counting systems)
graphics: pretty 3D surface plots
slider animations
HTML?