Risk of Ruin playing the WSOP ME - Page 2 - Gambling and Probability

Sherman · 09-30-2011, 02:55 PM

Quote:

Originally Posted by BruceZ

That link didn't work, but optimize usually means find the value that makes it a maximum. You want to find the value that makes it equal to zero. Actually what you have minus x should be zero. It is possible that the same routine can do both.

Ok. Sorry about the link.

typing "?optimize" without the quotes in R should bring it up (if again, you have the time).

This is what the help page says the function does though:
The function optimize searches the interval from lower to upper for a minimum or maximum of the function f with respect to its first argument.

It has a maximum= argument that can be set to TRUE to find the maximum instead. Either way, I think the output labelled, "objective" is what I want anyway. That should be the value of R in the equation tringlomane linked. At least I think it is...

If so, then we can take that number to the power of the number of BIs we want to solve Risk of Ruin for and we should be good to go right?

**BruceZ** · 09-30-2011, 03:17 PM

Quote:

Originally Posted by Sherman

Ok. Sorry about the link.

typing "?optimize" without the quotes in R should bring it up (if again, you have the time).

This is what the help page says the function does though:
The function optimize searches the interval from lower to upper for a minimum or maximum of the function f with respect to its first argument.

It has a maximum= argument that can be set to TRUE to find the maximum instead. Either way, I think the output labelled, "objective" is what I want anyway. That should be the value of R in the equation tringlomane linked. At least I think it is...

If so, then we can take that number to the power of the number of BIs we want to solve Risk of Ruin for and we should be good to go right?

Again, you don't want to maximize or minimize it, you want to set it equal to zero. It looks like you want to download and install a package called "BB" and use the utility called "nleqslv".

**BruceZ** · 09-30-2011, 04:16 PM

I figured there should be a simpler way built into standard R since even my pocket calculator can solve this equation. It turns out there is. Use either "polyroot" or "uniroot". They are already built in, so you can do ?polyroot and ?uniroot. The first does specifically polynomials. I just googed "R solve equations", which is usually the easiest way to find things.

Sherman · 09-30-2011, 05:22 PM

Quote:

Originally Posted by BruceZ

I figured there should be a simpler way built into standard R since even my pocket calculator can solve this equation. It turns out there is. Use either "polyroot" or "uniroot". They are already built in, so you can do ?polyroot and ?uniroot. The first does specifically polynomials. I just googed "R solve equations", which is usually the easiest way to find things.

I did the same and found uniroot() earlier...but I cannot figure out how to use the damn thing...at least not yet.

uniroot(function(x) sum(STTprob*x^STTprizes), c(0,1), tol=.000000001)

gives me an error that I do not understand:

Error in uniroot(function(x) sum(STTprob*x^STTprizes), c(0,1), tol=.000000001), :
f() values at end points not of opposite sign

It looks like the problem has something to do with the fact that if we use 0 for X we return Infinity which makes no sense to me.

Sherman · 09-30-2011, 06:58 PM

Ok, part of the problem had to do with the fact that I was using negative prizes (i.e. profits instead of prizes). If I use actual prizes though, this thing still doesn't work right.

uniroot(function(x) sum(c(.1,.1,.1,.7)*x^c(50,30,20,0)), c(0,1), tol=.000001)

As far as I can tell, this *should* work. But I get the same damn error message:

"values at end points not of opposite sign"

I looked through the code of uniroot and it first computes the function on the lower limit and the upper limit (0 and 1). If we run the function using 0 as X we get .7 and if we use 1, we get 1. Next, uniroot multiplies these together and if they are > 0 it does it returns the aforementioned error. So 1 * .7 > 1.

I tried using -1 and 1 to see what would happen and it still returns the same error. This blows my mind because if we us -1 in the function we get -1 and -1*1 = -1 which is less than 0. So why does this error appear? Sigh...

**BruceZ** · 09-30-2011, 07:57 PM

Quote:

Originally Posted by Sherman

Ok, part of the problem had to do with the fact that I was using negative prizes (i.e. profits instead of prizes). If I use actual prizes though, this thing still doesn't work right.

uniroot(function(x) sum(c(.1,.1,.1,.7)*x^c(50,30,20,0)), c(0,1), tol=.000001)

I thought that might be the case, but I assumed that you were using the STTprizes that you mentioned earlier. You actually need to use

c(50/11, 30/11, 20/11, 0)

because these need to be in units of buy-ins. x is the risk of ruin for a single buy-in bankroll.

Also, your function must equal x, so you need subtract x

sum(c(.1,.1,.1,.7)*x^c(50/11,30/11,20/11,0)) - x

so it equals zero. What you had before is > 0 everywhere on that interval, which is why you got the error.

If you do those things, you won't get an error, and it will return a root of 1 which will always be a valid solution to these problems. To return a solution less than 1, we need to change the upper limit to something slightly less than 1, like 0.999999. In this case, I haven't found this solution no matter how close to 1 I make the upper limit. So either it is too close to 1 to distinguish with finite precision, or the solution actually doesn't exist for these input numbers, which would be a weakness in the method because the risk of ruin should not be 1, even for a 1 buy-in bankroll, since we have a positive EV. EDIT: The EV is actually negative, and the formula is performing correctly. But when I change the first prize from 50 to 1000, it gives a result of about 83.2% which is the correct solution. I checked that the function f is computing the correct values even for your input numbers, so there is no problem with the call. You should get the correct results for your WSOP problem this way as triglomane did. In fact, if you use

c(0.0001, 0.2499, 0.75)

for the probabilities, and

c(5102, 2, 0)

for the payouts, meaning lose $1 with probability 75%, win $1 with probability 24.99%, and win $5101 with probability 0.01%, then you get the risk of ruin given in the first example of the article, or 99.99922%, which we then raise to the B power for a B dollar bankroll.

Sherman · 10-01-2011, 09:36 AM

Quote:

Originally Posted by BruceZ

I thought that might be the case, but I assumed that you were using the STTprizes that you mentioned earlier. You actually need to use

c(50/11, 30/11, 20/11, 0)

because these need to be in units of buy-ins. x is the risk of ruin for a single buy-in bankroll.

Also, your function must equal x, so you need subtract x

sum(c(.1,.1,.1,.7)*x^c(50/11,30/11,20/11,0)) - x

so it equals zero. What you had before is > 0 everywhere on that interval, which is why you got the error.

If you do those things, you won't get an error, and it will return a root of 1 which will always be a valid solution to these problems. To return a solution less than 1, we need to change the upper limit to something slightly less than 1, like 0.999999. In this case, I haven't found this solution no matter how close to 1 I make the upper limit. So either it is too close to 1 to distinguish with finite precision, or the solution actually doesn't exist for these input numbers, which would be a weakness in the method because the risk of ruin should not be 1, even for a 1 buy-in bankroll, since we have a positive EV. But when I change the first prize from 50 to 1000, it gives a result of about 83.2% which is the correct solution. In fact, it gives a solution of 89.9% for a payout of 90, but an error for 89 or below. That is odd behavior. I checked that the function f is computing the correct values even for your input numbers, so there is no problem with the call. You should get the correct results for your WSOP problem this way as triglomane did. In fact, if you use

c(0.0001, 0.2499, 0.75)

for the probabilities, and

c(5102, 2, 0)

for the payouts, meaning lose $1 with probability 75%, win $1 with probability 24.99%, and win $5101 with probability 0.01%, then you get the risk of ruin given in the first example of the article, or 99.99922%, which we then raise to the B power for a B dollar bankroll.

Hey Bruce,

Thanks for the help here. This is very useful. I think I have it performing correctly (as you do) now. However, in regards to the first problem we should actually have a negative EV because if it costs $11 to play and we lose .7 of the time that is .7*-11 + .1*39 + .1*19 + .1*9 = -1. That is, we should be losing to the rake. So my hope is that this would always result in 1.0 as the answer.

Sherman · 10-01-2011, 12:31 PM

Sorry this is getting kinda ridiculous, but...

Code:

p <- c(.1, .1, .1, .7)
Y <- c(50/11, 30/11, 20/11, 0/11)
uniroot(function(x) sum(p*x^Y) - x, c(0, 1), tol=.0000001)
p2 <- c(.2, .15, .12, .53)
uniroot(function(x) sum(p2*x^Y) - x, c(0, 1), tol=.0000001)
uniroot(function(x) sum(p2*x^Y) - x, c(0, .999999), tol=.0000001)
uniroot(function(x) sum(p*x^Y) - x, c(0, .999999), tol=.0000001)

Running these does not get the results I would expect for all cases.

So for the first one, we get 1 (with 0 iterations). That is is okay, because that is the right answer. For the second set of probabilities (p2) we also get 1. That is not the right answer. If I run that same thing again with the upper limit of .99999, I get the right answer. But if I try to run the first set of probabilities with .99999 as the upper limit, I get an error message.

This is a pain in the ass because it would be nice if this thing would provide the right answer no matter what probabilities I listed.

One work around, obviously, is to make it so that any losing probabilities would always return a root of 1 and that any non-losing probabilities would look for a root between 0 and .99999999. Because as you pointed out, 1 is a solution no matter what probabilities I give it.

**BruceZ** · 10-01-2011, 01:21 PM

You're correct about the negative EV for your original example. In fact, changing the first prize payout from 60 to 59 is what makes it go from positive EV to negative EV, and that is where the ror went to 1, so that makes perfect sense. I thought it was positive with your example because I was using the prizes array to compute the EV instead of the profits, LOL.

Quote:

Originally Posted by Sherman

Sorry this is getting kinda ridiculous, but...

Code:

p <- c(.1, .1, .1, .7)
Y <- c(50/11, 30/11, 20/11, 0/11)
uniroot(function(x) sum(p*x^Y) - x, c(0, 1), tol=.0000001)
p2 <- c(.2, .15, .12, .53)
uniroot(function(x) sum(p2*x^Y) - x, c(0, 1), tol=.0000001)
uniroot(function(x) sum(p2*x^Y) - x, c(0, .999999), tol=.0000001)
uniroot(function(x) sum(p*x^Y) - x, c(0, .999999), tol=.0000001)

Running these does not get the results I would expect for all cases.

So for the first one, we get 1 (with 0 iterations). That is is okay, because that is the right answer. For the second set of probabilities (p2) we also get 1. That is not the right answer. If I run that same thing again with the upper limit of .99999, I get the right answer. But if I try to run the first set of probabilities with .99999 as the upper limit, I get an error message.

This is all correct. With negative EV you will always get an error message when the bound is less than 1 because there is no solution less than 1, and you will get 1 when the upper bound is 1 because that is a solution. The uniroot function is doing what you asked correctly. Just use the formula for positive EV with a bound of 0.999999. With negative EV you know the answer is 1. Or you could probably set the result of uniroot to a variable and check it to trap the error case. I believe it returns a data structure with several values, and there is an example of parsing it in the function description.

Sherman · 10-01-2011, 01:23 PM

Ok...here is a solution for now:

Code:

RoR.iter <- function(prizes, probs, BI, BR) {
  if(sum(prizes < 0) > 0) {stop("Prizes must not be below 0.")}
  prizes.BI <- prizes/BI
  BR.BI <- BR/BI
  ROI.BI <- sum((prizes.BI-1)*probs)
  ifelse(ROI.BI < 0, R <- 1, R <- uniroot(function(x) sum(probs*x^prizes.BI) - x, c(0,.99999999999), tol=1e-70)$root)
  RoR <- R^BR.BI
  return(RoR) 
}

I updated the other Risk of Ruin simulation code as well:

Code:

RoR.sim <- function(prizes, probs, BI, BR, win=5*BR, sims=1000) {
  if(BR < BI) {stop("BR must be higher than BI.")}
  if(sum(prizes < 0) > 0) {stop("Prizes must not be below 0.")}
  if(sum(probs) != 1) {stop("Finish probabilities do not total 1.00. Please adjust input probabilities.")}
  if(length(prizes) != length(probs)) {stop("prizes and probs must be the same length (have the same number of elements).")}

  ROI <- sum((prizes-BI)*probs) / BI
  VAR <- sum((prizes-BI)^2 * probs) - ROI^2

  if(sims==FALSE) {
    tradRoR <- exp(-2*(ROI*BI)*BR/VAR)
    iterRoR <- RoR.iter(prizes, probs, BI, BR)
    out <- rbind("ROI %"=ROI, "Trad. Ruin %"=tradRoR*100, "Iter. Ruin %"=iterRoR)
    colnames(out) <- "Results"
    return(out)
  }

  res <- rep(NA, sims)
    print("Simulating...please wait")
    for (i in 1:sims) {
    simBR <- BR
      if(i == .25*sims) {print("25% of sims complete.")}
      if(i == .5*sims) {print("50% of sims complete.")}
      if(i == .75*sims) {print("75% of sims complete.")}

      while(simBR >= BI & simBR < win) {
        simBR <- simBR + sample((prizes-BI), 1, T, prob=probs)
      }
    res[i] <- simBR
  }
  tradRoR <- exp(-2*ROI*BI*BR/VAR)
  iterRoR <- RoR.iter(prizes, probs, BI, BR)
  out <- rbind(sims, BI, BR/BI, ROI*100, sqrt(VAR), tradRoR*100, iterRoR*100, (sum(res < BI) / sims)*100, (sum(res >= win) / sims)*100)
  rownames(out) <- c("Sims", "BuyIn", "BR (in Buyins)", "ROI %", "SD", "Trad. Ruin %", "Iter. Ruin %", "Sim. Ruin %", "Sim. Win %")
  colnames(out) <- "Results"
  return(out)
}

Some examples:

Code:

p <- c(.1, .1, .1, .7)
Y <- c(50, 30, 20, 0)
p2 <- c(.2, .15, .12, .53)

RoR.iter(Y, p, 11, 1100)
RoR.sim(Y, p, 11, 1100)

RoR.iter(Y, p2, 11, 1100)
RoR.sim(Y, p2, 11, 1100)

**BruceZ** · 10-01-2011, 03:45 PM

If you don't set the upper threshold high enough, sometimes it won't find the root even for positive EV when the EV is barely positive. For your original example, it actually changes from positive to negative when the first prize goes from 60 to 59, not 90 to 89 as I said before. But to not get an error at 60, you need an upper threshold of 0.999999999. That's 9 nines. With only 8 nines, you get an error.

One way to flag the error condition is to set the output of uniroot to a variable, and before calling it, set that variable to some error value like 999. When you get the error, it doesn't change this value, so it will still be there. But when you don't get an error, it returns several values in a structure, so checking it like it is an ordinary variable will generate a warning. It will work, but it's ugly. You could find a more elegant solution, such as checking if the type of the variable changed without generating a warning.

It would be nice if you could just use an upper threshold of 1, and have it give you the lowest root, but it insists on giving you the highest root when the root is 1. In Excel, you give it a starting value lower than the actual root, like 0.5, and then it doesn't have this problem.

**BruceZ** · 10-02-2011, 12:20 AM

Actually you can handle both the case of negative ev and the case of the threshold not being high enough just by making sure that the value of the function at the upper limit is negative, so you wouldn't need the ev.

Code:

bankroll = 1   #buy-ins in bankroll
buyin = 11
prizes = c(10, 30, 20, 0)
prob = c(.1, .1, .1, .7)

ev = sum(prob*(prizes-buyin))
prizes = prizes/buyin
f = function(x) sum(prob*x^prizes) - x
lower = 0
upper = 0.999999999
r = 1
if (f(upper) < 0) {
  val = uniroot(f, c(lower, upper), tol=1e-10)
  r = val$root
}

ev
r^bankroll

Sherman · 10-02-2011, 09:40 AM

Hmmm...has got me thinking about rounding issues. I'm not sure if it is my computer or R, but I can only type 7 digits of .9999999. At the 8th digit it treats it as 1.0. Obviously that is somewhat of a problem here.

.999999 # Returns .999999
.9999999 # Returns .9999999
.99999999 # Returns 1
.999999999 # Returns 1

**BruceZ** · 10-02-2011, 03:21 PM

Quote:

Originally Posted by Sherman

Hmmm...has got me thinking about rounding issues. I'm not sure if it is my computer or R, but I can only type 7 digits of .9999999. At the 8th digit it treats it as 1.0. Obviously that is somewhat of a problem here.

.999999 # Returns .999999
.9999999 # Returns .9999999
.99999999 # Returns 1
.999999999 # Returns 1

I see that too. I think it has to do with the way the number is displayed by default. You should be able to change that. Internally the number should be more precise than that. There is also double precision. I think the documentation for uniroot shows displaying a certain number of digits.

tringlomane · 02-04-2012, 12:47 AM

bump for general utility