Thread Rating:

Poll

3 votes (13.04%)
4 votes (17.39%)
7 votes (30.43%)
2 votes (8.69%)
2 votes (8.69%)
5 votes (21.73%)
1 vote (4.34%)
4 votes (17.39%)
7 votes (30.43%)
6 votes (26.08%)

23 members have voted

bobbartop
bobbartop
Joined: Mar 15, 2016
  • Threads: 125
  • Posts: 2542
July 27th, 2016 at 9:25:32 PM permalink
Quote: beachbumbabs

Well, that's disappointing. I had thought you were playing for the entire amount, sort of "earning" the bonus amount with the playthrough. At the end they take back the bonus amount? Wow.

So if I deposit 500, they match 500, I play through 30x the total amount, and end up with, say, a balance of $550 (already an incredibly lucky situation). If what you're saying is true, I didn't win $50, I lost $450, once they take their bogus award back.

I'm appalled I ever even tried this, which I did with Bova da a couple times last year. Never again.

Are they all like this? What a scam.




Not a scam. Very beatable, "phantom bonus". When I first started, it was all cashable bonuses. The first guys I remember doing phantom was some of the Playtech guys started going that way. Some guys started "sticky" bonuses, and then phantoms. I just don't mess with it anymore. Knocking out us Americans screwed up the whole deal.

When I first discovered the online gravy train in about 2001, I never left my bedroom. It was great. I could lose $100 before I brushed my teeth. I shoulda got rich. Some people did.
'Emergencies' have always been the pretext on which the safeguards of individual liberty have been eroded.
BleedingChipsSlowly
BleedingChipsSlowly
Joined: Jul 9, 2010
  • Threads: 20
  • Posts: 933
July 28th, 2016 at 4:50:45 AM permalink
This is the Javascript solution algorithm I posted, reworked as a function and with character escapes added so that the site posting reflects the text as intended. Reference my previous posting if you want to see a commented version.
function pRuin(bankroll,bets,pWin) {
const pLoss = 1 - pWin;
var bp =[];
for (let i=0; i<=bankroll+bets; i++) {bp[i]=0;}
bp[bankroll] = 1;
for (let bet=1; bet<=bets; bet++) {
let br = bp.slice(0);
for (let i=Math.max(bankroll-bet+1,1); i<bankroll+bet; i++ ) {
if (bp[i] > 0) {
br[i-1] += bp[i] * pLoss;
br[i+1] += bp[i] * pWin;
br[i] -= bp[i];
}
}
bp = br;
}
return bp[0];
}

The solution quickly provides an exact answer, not an estimate. Is it too simple to be acceptable? Not math-heavy enough for this forum?

<!doctype html>
<html><head><script>
function pRuin(bankroll,bets,pWin) {
const pLoss = 1 - pWin;
var bp =[];
for (let i=0; i<=bankroll+bets; i++) {bp[i]=0;}
bp[bankroll] = 1;
for (let bet=1; bet<=bets; bet++) {
let br = bp.slice(0);
for (let i=Math.max(bankroll-bet+1,1); i<bankroll+bet; i++ ) {
if (bp[i] > 0) {
br[i-1] += bp[i] * pLoss;
br[i+1] += bp[i] * pWin;
br[i] -= bp[i];
}
}
bp = br;
}
return bp[0];
}
</script></head><body><script>
document.write(pRuin(25,100,0.49));
</script></body></html>
“You don’t bring a bone saw to a negotiation.” - Robert Jordan, former U.S. ambassador to Saudi Arabia
ThatDonGuy
ThatDonGuy
Joined: Jun 22, 2011
  • Threads: 99
  • Posts: 4759
July 28th, 2016 at 6:44:20 AM permalink
Quote: BleedingChipsSlowly

This is the Javascript solution algorithm I posted, reworked as a function and with character escapes added so that the site posting reflects the text as intended.
The solution quickly provides an exact answer, not an estimate. Is it too simple to be acceptable? Not math-heavy enough for this forum?


Too simple? Not math-heavy enough? Not at all - plus, bp[1] through bp[bankroll + bets] end up with the probabilities of ending with each possible ending value, if you're interested in that.

The only "problem," if you can call it that, is, you have to build an array for each bet, and it increases in size from one bet to the next. For low numbers of bets, that's not going to be a problem, but what happens when you have a large number of bets? (I think it comes down to, just when does the Java VM garbage collect the br array created in each iteration of the bet for loop.)

Then again, you can get around that by having a single array of size (bankroll + bets + 1), and alternating between calculating the odd-index values and the even-index values (remembering to add elements 0 and 1 to get the new value for element 0). In this case, you have to remember that, at the end, half of the values in the array (the ones not calculated in the final bet step) are invalid.
BleedingChipsSlowly
BleedingChipsSlowly
Joined: Jul 9, 2010
  • Threads: 20
  • Posts: 933
July 28th, 2016 at 8:12:53 AM permalink
Quote: ThatDonGuy

Quote: BleedingChipsSlowly

This is the Javascript solution algorithm I posted, reworked as a function and with character escapes added so that the site posting reflects the text as intended.
The solution quickly provides an exact answer, not an estimate. Is it too simple to be acceptable? Not math-heavy enough for this forum?


Too simple? Not math-heavy enough? Not at all - plus, bp[1] through bp[bankroll + bets] end up with the probabilities of ending with each possible ending value, if you're interested in that.

The only "problem," if you can call it that, is, you have to build an array for each bet, and it increases in size from one bet to the next. For low numbers of bets, that's not going to be a problem, but what happens when you have a large number of bets? (I think it comes down to, just when does the Java VM garbage collect the br array created in each iteration of the bet for loop.)

Then again, you can get around that by having a single array of size (bankroll + bets + 1), and alternating between calculating the odd-index values and the even-index values (remembering to add elements 0 and 1 to get the new value for element 0). In this case, you have to remember that, at the end, half of the values in the array (the ones not calculated in the final bet step) are invalid.

Thanks for your thoughtful commentary, your points are well taken. Actually, the array size is initialized for all bets, it doesn't expand. I thought of expanding the array for each bet but decided against that for simplicity. Likewise, the code design assumes the VM garbage collection works well. I tend not to code solutions for problems unless they present themselves. As to a practical limitation on the number of bets I had no problem processing 10000 in less than a second. That represents more than 15 hours of rabid gambling by my reconing, which I think covers the problem domain. A million bets does not precess well, but that would represent a more than a week of nonstop gambling. I hardly think free play offers are made with the intention of providing patrons with more than a brief time of play.
“You don’t bring a bone saw to a negotiation.” - Robert Jordan, former U.S. ambassador to Saudi Arabia
LuckyPhow
LuckyPhow
Joined: May 19, 2016
  • Threads: 52
  • Posts: 678
July 28th, 2016 at 2:45:39 PM permalink
Quote: Wizard

I've been tasked with assessing the general value of Internet casino bonuses given certain parameters. I find it is necessary to have a general formula for the probability of ruin. I've seen such formulas before but they all seem to be based on infinite steps until a given goal is met or ruin.



Wow! For me, this has been a fascinating, interesting, educational thread, and I wanted to take a minute to thank the many Stat Wizards for sharing. Thanx for all the detailed back-up calculations that helped explain what you were saying. And, the external references. (My first read of the Morin article says it needs more careful examination, but thanx MustangSally. Haven't yet done justice to miplet's web reference, but what I saw says, "Come back when you can visit longer.") You know who you are, but thanx to ThatDonGuy who tried to steer me on a better tack, and BleedingChips and Romes, and anyone else I missed. I feel like I just happened to step into the faculty lounge where everyone was discussing a problem posed by last week's guest lecturer, and, what a discussion it is!

As for the Wiz, I sorta feel like I'm the dog riding in the back of the pick-up truck. I'm not quite sure where he's going or why. But, I'm sure enjoying the ride. And, once we get there, it'll probably be even more fun, don'cher know?

  • Jump to: