Did you look at this part of the Wikipedia article? ...k_c said:
Indeed. The purpose of my randint(n) function is to produce an unbiased, random number in the range 0..n-1. This is needed for use by the Knuth (aka Fisher-Yates) shuffle ...k_c said:
well, thank you very much fabietto!fabietto said:
London Colin said:
Implementation of Durstenfeld's algorithm in ObjectiveC is:
int n = [someMutableArray count];
while ( n > 1) {
int rnd = arc4random() % n;
int i = n - 1;
[someMutableArray exchangeObjectAtIndex:i withObjectAtIndex:rnd];
n--;
}
. In the first iteration the last card can be swapped with any card, including itself. In the next iteration the next to last card can be swapped with any card including itself but excluding the last card. Each succeeding iteration eliminates more and more cards until the initial card is encountered and in that case the only possibility is that that card must be swapped with itself.The example of a deck of just three cards makes it clear.k_c said:
[B]Swap #1 Swap #2 Swap #3 Final Ordering[/B]
(1,1) = ABC (2,1) = BAC (3,1) = CAB
(3,2) = BCA
(3,3) = BAC
(2,2) = ABC (3,1) = CBA
(3,2) = ACB
(3,3) = ABC
(2,3) = ACB (3,1) = BCA
(3,2) = ABC
(3,3) = ACB
(1,2) = BAC (2,1) = ABC (3,1) = CBA
(3,2) = ACB
(3,3) = ABC
(2,2) = BAC (3,1) = CAB
(3,2) = BCA
(3,3) = BAC
(2,3) = BCA (3,1) = ACB
(3,2) = BAC
(3,3) = BCA
(1,3) = CBA (2,1) = BCA (3,1) = ACB
(3,2) = BAC
(3,3) = BCA
(2,2) = CBA (3,1) = ABC
(3,2) = CAB
(3,3) = CBA
(2,3) = CAB (3,1) = BAC
(3,2) = CBA
(3,3) = CAB(3,1) = CBA (2,1) = BCA
(2,2) = CBA
(3,2) = ACB (2,1) = CAB
(2,2) = ACB
(3,3) = ABC (2,1) = BAC
(2,2) = ABCYou have me convinced, There are definitely 27 possibilities in your 3 card example and 6 equally likely orders that are needed. It's impossible that 27 equally likely possibilities can be representative of 6 equally likely orders.London Colin said:
Hi mate... let's see then...ExhibitCAA said:
Thanks for the hint. As I mentioned before, I'm not an expert of the game, so this kind of information about how the "typical" games are played are very important to me. I've modified the simulator, letting the user to decide how to mange the split of aces (considering it as every other kind of split or ending his turn). I've also added a maximum number of splits allowed (4). I guess anyway that the likelihood of splitting more than 4 hands is very low. Of course it will happen in the long run, but its effect has to be marginal at best.ExhibitCAA said:
Yes, that's what I'm doing. I check for naturals (and eventually pay them 3-to-2) before the hand is played, so there's no risk that a 21 made with more than two cards would be payed 3-to-2. The only thing I'm not sure about (and I was discussing with John) is who to check first. In the current version of the simulator I check first for a blackjack dealt to the player, then for a blackjack dealt to the dealer. I don't know it this might be an issue. If I'm not wrong, the order should not significantly affect the game (if the dealer has a natural and the player doesn't, the hand finishes anyway; the same if the player has a natural and the dealer no).ExhibitCAA said:
Lol... would be funny to do that from time to time... I could pretend to take into account dealers' mistakes...ExhibitCAA said:
That's the function I'm using in my software. According to the documentation (http://stdcxx.apache.org/doc/stdlibref/random-shuffle.html), the elements in the array are shuffled according to a uniform distribution. Seems to me a good and easy way to obtain a proper shuffle. Might be interesting to see if calling multiple times (i.e., at the beginning of each trial) the std::rand() function makes any differences compared to just calling it once at the beginning of a simulation.London Colin said:
ok icnt, i see the difference.iCountNTrack said:To further clarify what is being correctly mentioned here.
The expectation value calculated from basic strategist/counter is only dependent on the deck/shoe composition and the house rules. The sequence of the cards does not really matter per say, because the ev of a particular composition is an average value for millions of sequences of that composition. However, for the results of a simulation to match those of a combinatorial analysis (for CA as k_c mentions only ONE shuffle/sequence is needed) , millions of shuffles and an ideal RNG is a must.
To illustrate this point, the ev of a 6D DAS S17 game with optimum play(BS) using CA is -.402%
The following image has two sims of the same game except that the first one uses the RNG of Cvdata to generate random shuffles and the second is very non-random shuffle where two 156 card grabs are riffled once. Please note how close the ev (IBA) of the first sim (-0.398%) to the value obtained from CA, and how off is the ev obtained from the second sim (-0.560%).
:whip::whip: but it could happen.:whip: