> What is "Sorokin Optimized"? Went to the above-line and couldn't
find
> anything there about it.
>
> Thanks.
>
> Bill Velek
you have to solve for the sorokin number R(1) first
the equation is: R(1)= sum(Pi x R(1)^Wi)
where Pi is the hand probability and Wi is the win value
you sum this for each winning hand, i.e, rf, sf, quad ... and also
the no win hand
the result, R(1) is also an input to the equation, so you have to
iterate to find the solution, but this can be done using a spreadsheet
for double bonus you get a number like .99988
Or 0.9998757753249636, to be more precise.
this number can be used to determine your risk of ruin for any
bankroll using the following formula:
ror=R(1)^Bankroll
for example, for a bankroll of 10,000 units:
ror=.99988^10,000=.3=30%
with R(1) we can also solve for optimum bankroll growth
to do this, we use this formula to adjust each payout:
Wnew=(1-R(1)^Wold)/(1-R(1))
for example, for the royal:
Wnew=(1-.99988^800)/(1-.99988)=763
This is what I refer to as "virtual payoffs". Using the more precise R
gives 761.57786 for the virtual payoff of the royal flush.
plug these new values into a strategy generator, like vpsm, and you
get the sorokin optimized strategy
Actually, you may have to iterate over this process a few times in
order to get an optimal solution. This gives the strategy that I
call "min-risk". You'll know the solution is optimal because the
min-risk strategy has one other special property -- the optimized
strategy with the virtual payoffs gives a virtual return that is
exactly 100.000000000%. In other words, a breakeven game.
Any departure from the min-risk strategy will cause RoR to increase.
on this example, double bonus, not much changes, because the game is
barely positive, but, for example, on a game like all american or
with strong cashback you get quite a few changes
bottom line, with regards to bankroll growth, the high value payoffs
are overvalued for the risk involved
For favorable games, the virtual payoffs are all less than (or equal, for
a payoff that amouts to a push) the real payoffs. For unfavorable games,
the virtual payoffs are all greater than or equal to the real payoffs.
The concept of virtual payoffs, combined with a specific mathematical
expression that relates real payoffs to virtual payoffs based on some
parameter (I usually call the parameter R), can be used to find optimal
strategies for a wide variety of "perspectives" on what is meant by
the word "optimal".
This whole process can be framed in mathematical terms to show that
games such as VP can be "decomposed" into subgames that give a
representation that is mathematically equivalent to the original game.
This decomposition can be performed in a virtually infinite variety of
ways.
In a previous post, titled "Equivalent Games", I showed how to
reduce an 8/5 JoB VP game into several subgames that were each
based on a series of coin flips of the same biased coin. This was
based on a "risk" representation, and demonstrates that the
risk representation of a strategy reduces the strategy to a
random walk based on a biased coin. Among all possible
representations of a given strategy, only the risk representation
allows the same biased coin to determine the outcome of all
payoffs.
Strategies such as min-cost (for overall cost), min-cost(royal), and
min-cost(whatever-payoff) can all be derived using the concept of
virtual payoff scedules. In all cases, the optimal strategy is found
by adjusting the virtual payoffs and plugging them into a strategy
optimizer, and iterating over those two steps until the strategy
optimizer yields a strategy that gives a breakeven game.
Breakeven games have (at least) one very special property. For
a breakeven game, each payoff occurs just often enough to pay
for the cost of that payoff.
I've been developing the concept of virtual payoff schedules over
the last few months. I'm still doing a lot of experimenting with the idea,
but it is producing a lot of interesting results.
···
On Sunday 04 January 2004 08:39 pm, aaquad250 wrote:
--- In vpFREE@yahoogroups.com, Bill Velek <billvelek@a...> wrote:
