The instruction counters I referred to were PNGs. The PNG then is a ‘linked list’. Why would it function differently in your randomizer than a linear counter?
Clarification - 51 position PNG and 51 position linear counters are both linked lists with identical sets of values - just in a different fixed order.
I"m not entirely sure what you’re nitpicking here. I was pointing out in my reply that a single riffle is not a shuffle, and then I described what was commonly regarded as a “shuffle” – a whole process of randomizing, not just single riffle. The salient point was the shuffle as a process to achieve randomization or near-randomization not a single interleaving event. What you describe is essentially the same as what I’m describing. Riffles, followed by cuts (or, in my case, overhand shuffles, which is essentially the same) followed by riffles. So I don’t get the nitpick at all.
Every pseudorandom number generator has a cycle or cycles of finite length, after which it’ll repeat the same exact cycle. For the good ones, there’s only one cycle, and it’s very long (long enough that, in practice you’ll never get through all of it), but it’s still finite. It’s also, for all the implementations I know of, a power of 2, and can therefore never be a multiple of 52! .
How would one go about estimating (or calculating) the “birthday problem” on this? That is, given 52! possible “birthdays” how many people would you need in the sizable room for there to be better than even odds a pair share a birthday?
And, the PNG will generate all possible combinations the same as a linear counter. When you work with computers that use a PNG for the instruction counter, you quickly begin to think in the shift sequence. It is no longer ‘random’.
For any collection X there are X*(X-1) unique pairs. If the total space of possible elements in X is N. Then if X*(X-1) > N/2 there is over a 50% chance there’s a match.
So here N is 52! so X has to be pretty darn close to sqrt(52!/2).
Look, what I’m saying is conceptually very simple. If you have a capable algorithm for generating pseudo-random numbers, and it’s initiated by a putative random seed of sufficient length for the intended purpose, then its output will be, for all practical purposes, a random series, limited only by whatever limitations the algorithm might have.
As for what you’re saying, I honestly have absolutely no idea what you’re saying or what you think it demonstrates. In order to be useful, computers have to execute instructions deterministically, either in a logically sequential fashion (by auto-incrementing the program counter in the case of sequential addresses, or following the forward pointer if you want to introduce the linked list paradigm), or else by branching in accordance with its inputs or their derived computations. What this has to do with random number generation is truly mystifying. Maybe you can try to explain its relevance more clearly, and perhaps link to an example of one of these hypothetical machines so I can figure out what on earth you’re talking about.
What is the cycle length of the Chudnovsky algorithm?
So that’s 6.35e+33. Still pretty big, but somewhat more manageable. Amazing what shaving off a few dozen orders of magnitude will do for you.
We have about 4.35e+17 seconds since the big bang. We “only” need to shuffle 10e+16 decks every second since, and we have about a 50% chance that two of those sequences were the same.
I was asking about the long term statistical effect of using a PNG in this application. The PNG can provide an instantaneous value that appears to be random. But, long term it is statistically the same as a linear counter of the same length.
I gave as an example that PNG counters have been used as a one to one replacement of linear counters in computer instruction registers. There is no arithmetic difference. Shift counters are used because they have fewer parts, and no end to end propagation delay, so have an advantage in some computer architectures. But they are just counters and their non-linear sequence is not random. Perhaps it was a poor choice, sorry.
The problem is, we don’t verify, so we can’t really know, now can we? Excuse me, I’ve got to get on my way off to Buffalo.
What statistical effects do you mean? Typical pseudo-random number generators people use are, naturally, not random, and they have some sort of period (let’s say really big, a lot more than 52! anyway), but they also have desirable statistical properties like some sort of equidistribution.
I re-read the original posts to see where I diverged. Wolfpup was proposing very large PNGs, I was thinking in terms of those normally found in computers. It was a rabbit hole. Thanks for the reply.
Isn’t there a Doper whose job is (or was) determining whether online casinos’ software/RNGs were in fact producing sufficiently random results? I forget their name otherwise I’d tag them - I’m sure they would have something interesting to say on this.
When I used to deal in poker rooms, my SOP for each hand was a ‘wash’ to begin with (no better way to truly randomise the order IMHO), 3 riffles, one hand over hand shuffle, then 3 more riffles (and then a cut to finish, of course). I think having an odd number of riffles is good in order to reduce the effect of 2 perfect (or nearly so) riffles cancelling each other out. I don’t recall any complaints from players either that I was too slow between hands or that the shuffles weren’t sufficiently random. I believe I copied this technique from the one the dealers employed by the casino used.