which should be, given a good randomness, literally equivalent to drawing randomly from a pool of 52 cards to form a deck. Is this somehow less efficient than their algorithm?
Re:How We Learned to Cheat at Online Poker: A Study in Softw...
by solutionyogi on Monday July 20, 2015 @02:22PM
(#9917960)
I think the problem is the randomness.
When you use your language's random function, you are getting a pseudorandom generator. As noted in the article, they were able to figure out the seed for the random function. Once you know the seed, the game is over. The adversary can now figure out the exact shuffled deck.
Re:How We Learned to Cheat at Online Poker: A Study in Softw...
by astrodust on Monday July 20, 2015 @02:35PM
(#9918048)
The algorithm is not the problem. The "good randomness" part is the entire problem.
Easy way to shuffle a deck is just to give each card a random 32-bit index and sort. You don't need to do anything fancy to get them shuffled up. The problem is, if your random number generator is predictable then the algorithm doesn't matter.
Re:How We Learned to Cheat at Online Poker: A Study in Softw...
by AndrewStephens on Monday July 20, 2015 @03:16PM
(#9918329)
Even that is very slightly biased, since you don't specify what happens when 2 cards accidentally end up with the same index. It's better to do the shuffle described in the document.
It is not just the predictability of the generator that is the issue (all PRNG are predictable really), what really matters is the size of the seed state, which should vastly exceed the number of value shuffles (52! - a huge number).
Re:How We Learned to Cheat at Online Poker: A Study in Softw...
by rav on Monday July 20, 2015 @02:19PM
(#9917933)
That is essentially the same as the algorithm in the article, which was Figure 3:
for (i is 1 to 52)
Swap i with random position between i and 52
After i iterations, the first i entries are your "shuffled", and the last 52 - i entries are your "cards". "random.choice(cards)" corresponds to picking a "random position between i and 52".
Re:How We Learned to Cheat at Online Poker: A Study in Softw...
by lmm on Monday July 20, 2015 @02:38PM
(#9918069)
But they didn't do that - they picked a random position between 1 (not i) and 52 each time, which gives a biased shuffle. Even if their randomness had been perfect, this would have been problematic.
Re:How We Learned to Cheat at Online Poker: A Study in Softw...
by eximius on Monday July 20, 2015 @02:24PM
(#9917967)
I suppose. I guess I just prefer the more direct, naive algorithm when the performance gain would seem to be so small. (not that I've profiled it or anything :/)
Re:How We Learned to Cheat at Online Poker: A Study in Softw...
by rav on Monday July 20, 2015 @02:27PM
(#9917999)
From a CS theory perspective, I would say it's two implementations of the same algorithm, or two ways of phrasing the same algorithm. The most natural formulation in your eyes is probably not the same as the most natural formulation in the eyes of the article author.
Depending on the array implentation, adding and removing elements is often an O(n) operation, which isn't terribly efficient. The Fisher-Yates method lets you get the same results without messing with the array length.
Re:How We Learned to Cheat at Online Poker: A Study in Softw...
by erikb on Monday July 20, 2015 @01:45PM
(#9917697)
I'd be really interested in articles after 2008. About 2005-2007 is when the internet poker boom was on its height. I'd say in that area there must have been a lot of progress, because there was a lot of money in it, a lot more than now or 1999.
Re:How We Learned to Cheat at Online Poker: A Study in Softw...
by Justin_K on Monday July 20, 2015 @01:59PM
(#9917808)
Well your site doesn't explain anything about how it technically works or what steps you go through for certification. Your demo doesn't work and appears to be a phony flash demo anyways. What kind of bond do you carry to support your guarantee? It's pretty easy to conclude that your service is a scam.
When you use your language's random function, you are getting a pseudorandom generator. As noted in the article, they were able to figure out the seed for the random function. Once you know the seed, the game is over. The adversary can now figure out the exact shuffled deck.
Also see: http://ericlippert.com/2013/05/06/producing-permutations-par...
Easy way to shuffle a deck is just to give each card a random 32-bit index and sort. You don't need to do anything fancy to get them shuffled up. The problem is, if your random number generator is predictable then the algorithm doesn't matter.
It is not just the predictability of the generator that is the issue (all PRNG are predictable really), what really matters is the size of the seed state, which should vastly exceed the number of value shuffles (52! - a huge number).
Depending on the array implentation, adding and removing elements is often an O(n) operation, which isn't terribly efficient. The Fisher-Yates method lets you get the same results without messing with the array length.