CSM'S

If you generate a "shoe" of numbers as he suggested, then start generating pairs of (starting point, stride) as he also suggested, and you use that to produce a bunch of random numbers, if there is a problem with them I'd think that something like "the poker test" would fail. If we deal N 5-card poker hands, we know how many ought to be a single pair, two pair, three of a kind, etc. This is the most common test that the RNGs I have seen students come up with off the net seem to fail.

One example from last semester was that the student found the series 1,2,3,4,5 somewhere in the billion numbers and said "how can that possibly be random?" I asked "what's the probability of getting a straight flush (which that represents) in poker? Is it 0.0 or is it something a little higher? They thought and said "ahhh... you mean that if I did _not_ see a 1,2,3,4,5 ever, the numbers would not be random?" And another "light" comes on. :)

In my testing, I never have tried to test a "single shoe" for the very reason you gave. To solve this, my randomness testing has usually used "penetration". That is, students will generate a shoe of 6 decks, extract 260 cards leaving 52 in the shoe, then re-shuffling. Now since we cut off that deck, we don't get perfect uniformity since cards were left. But uniformity tests still tend to raise a red flag....I've typically used large numbers as well. A few years back I actually ran one trillion random numbers thru a test using a Cray, which could deal with 64 bit values easily and which had the ability to produce 64 bit random numbers with a period that was huge...

The thing I don't like about "shoe[0] and shoe[rnd]" is that can thrash cache badly, and can run slower. The shoe array and the code fiddling with it have to map into cache without colliding, and the bigger the shoe[] array is, the more likely colliding with code lines becomes. Not that big a deal with todays fairly large L2 cache sizes, but an issue.

On a good 64 bit processor like the opteron, each of the 10 card[n] values can be kept in registers (opteron has 8 extra thank goodness) so that no cache references are needed, and the simple approach I gave can actually run faster even though it seems to be doing a little extra work with the subtractions...

But back to the current discussion, I simply feel a bit uneasy about generating a string of pseudo-random numbers and then using a random starting point and stride to access them. I wonder how strong the correlation will be between sets of the numbers produced from the same starting "shoe". KISS (not the counting system) or Occam's razor seems to apply here, IMHO. When I feel a bit uneasy about something, I've learned to go with that feeling to avoid a lot of wasted time and effort that eventually just confirms it was right. :)

I've seen RNGs where the raw sequence produced looks perfectly random, but if you take every third number, it suddenly fails some test. Proving something to be acceptably random is quite a chore... But even worse, if you don't prove it, the results can be skewed without anyone knowing. The really good RNGs have been tested exhaustively, but the tests are done on the stream "as produced". Rather than on every Nth value or whatever, which might well have a different result. Hence my preference to use the thing as it has been tested...

Well, I guess I was looking for something a little more substantive than "I simply feel a bit uneasy" about this algorithm. As I said in my initial post, I tried several techniques that really didn't work very well, but believe it or not, I wouldn't have posted this one if it didn't seem to work pretty well. I seriously doubt that the "Poker test" would show any anomalies not also evident in the original shuffle-every-shoe version of PowerSim (if any), but not hearing any better ideas, I have decided to use something like the BJ equivalent of a Poker test to see if there appears to be any correlation effect. At least for this initial test, I'm going to run a series of sims where only one round is dealt from each "shoe", so the results should be close to the off-the-top results derived from combinatorial analysis of the game. I've also included counters to count the number of doubles, splits, BJs, and dealer BJs, since it's fairly easy to look for any skewing with those hands. I'm going to use a 2-deck H17 DAS game, simply because that's one of the strategy files included with PowerSim, but I'm not really going to be concerned with how well the results agree with the CA results (that's a different issue -- one that ET Fan may be interested in); I'm simply going to see how well the two versions of PowerSim agree with each other.

So far, I've only run 5 sims with each version, for 250 million rounds each. (The original version of PowerSim takes my machine about 48 minutes, because it's shuffling every round; but to give you an idea of why I think this is worth exploring, my version runs in about 6 minutes.) Here are the results so far (and I'm going to intentionally not tell you which is which -- see if you can deduce that, if you can detect any skewing):

 

            IBA    Variance Doubles  Splits  PlayerBJ DealerBJ 

--------------------------------------------------------------  

        -0.0039623 1.349814 27905371 6446161 11945563 11945504 

        -0.0039016 1.349603 27896379 6442394 11947476 11950596 

        -0.0040148 1.349615 27898440 6438919 11943365 11944057 

        -0.0038521 1.349830 27899716 6449158 11952792 11947081 

        -0.0039522 1.349951 27910687 6447544 11951728 11946182 

  

Mean    -0.0039366 1.349763 27902119 6444835 11948185 11946684 

StdDev  6.2016E-05 0.000150 5836.163 4145.56 4012.083 2449.841 

--------------------------------------------------------------  

        -0.0039428 1.349698 27899202 6439884 11957106 11945962 

        -0.0040625 1.349659 27896763 6443696 11948789 11952091 

        -0.0038231 1.349902 27910293 6445111 11956127 11953983 

        -0.0038685 1.349624 27895820 6442509 11946823 11946308 

        -0.0039809 1.349797 27910512 6443305 11947591 11948164 

  

Mean    -0.0039356 1.349736 27902518 6442901 11951287 11949302 

StdDev  9.4029E-05 0.000113 7302.974 1932.31 4927.323 3574.386 

My concern with this type of enhancement is not that you would get inaccurate results. It's that you might not be getting the statistical significance you think you're getting.

For example, it's conceivable to me that if you do a 2 billion round sim with the "fast shuffle," you actually get the same significance as a 1 billion round sim with the regular shuffle. If that turns out to be true, you're actually doing a longer sim to get less significant results!

I don't think any length sim is ever going to show this one way or the other with any degree of certainty. What you need is many short sims, so you can plot the win rates and see how well they follow the normal distribution. For example, if you do 500 one-million round sims, you know that a certain number should be 0.5, 1.0, 1.5, 2.0 and 2.5 standard deviations from the mean based on what we know about the distribution of a one-million round sim. You can compare this to what you'd predict for 500,000 round sims, or two-million round sims.

In other words, a difference might show up in what I think you're calling the standard deviation of the IBA. 6.2016E-05 versus 9.4029E-05. But a lot more trials are needed to know if this is significant. Each individual sim needs to be at least as long as one of your long "shoes."

I'm not saying this would be a complete and sufficient test for your innovation. This is tough, untrod terrain. Your IBA SD might also be less than the regular shuffle. In that case, your results are "stratified," to some degree, using Griffin's terminology. That would be important to know as well.

I did a few tests that make me think most of the shuffle time is taken up by the two floating point operations for each card shuffled. One FP multiplication gets the random number in the range 0 <= Rnd < 1, and another gets it in the range 0 <= INT(Rnd) < i. It would be easy to reduce that to one FP operation, and not too hard to eliminate both FP operations with a table look up scheme. It wouldn't be quite as fast as your system, but it would go a long way. If you have time, you might want to look into it.

Best,
ETF

I would not panic about the cost of the floating point operation or operations. Why? The FP hardware is a completely separate "pipe" in the X86. A good compiler will order/schedule the instructions so that the fp operations are done in parallel with the rest of the instructions inside the loop, and the bottom line is that they might have _zero_ cost associated with them, depending on exactly what is being done inside the loop.

In linux, I often compile things (using gcc) with the -S option, which gives me a .S file that contains the optimized assembly language instructions used to execute the C-code algorithm. You can look at that pretty carefully to figure out whether the FP operations are painful or not. Often a good optimizing compiler finds clever ways to hide part of the instruction mix in the latency of the other instructions, making parts of an instruction stream essentially free (no computational delay/cost).

Procedure calls are not free, but a good compiler will inline things assuming you compile your own PRNG code along with the calling code. Using a library PRNG will be more expensive since it can't be inlined.

It's _way_ more important to first figure out where the time is going, before trying to figure out how to speed things up by actually modifying the code. Quite often the time goes into a surprising piece of the code rather than the obvious piece.

BTW, I agree with your comment 100%. You may well get good answers, but not as good as expected. For example, in my "blackjack simulator project" occasionally a student will miss the class where I talk about the random number problem, and when they "distribute" the simulation over multiple machines, they use the _same_ PRNG on all of them. Which is the same thing as running the same sim N times rather than running the sim using N times more hands played. I could tell you about other amusing attempts that have blown up in their programs in the past, but it's not that relevant here.

Suffice it to say that it is easy to screw up the randomness without realizing it.

Sorry for being a bit "vague". But this really requires a _lot_ of testing, which means a lot of time. To conclude anything at all would require a big time investment, and obviously most are not going to be willing to go that deeply into the question.

I've had the opportunity to be involved in lots of simulation projects over the years. And surprisingly, the majority of the problems turn out to be with the random numbers rather than with how they are used. It is _surprisingly_ difficult to really produce random numbers. Or even to produce a random starting "seed". Sample the cpu clock every so often and grab a few bits and combine with other samples can sound good. But if you are not carefull, the "timing" becomes repetitious, and suddenly those "random seeds" are predictable, ruining the result.

Einstein once said "nothing is truly random". I've become convinced. :) That's why there are so many different PRNG tests around. One has been found to be "not enough"...

You may very well get answers that look the same. But that is just as true as if you ran half as many rounds. And you won't know the standard error. Monte Carlo methodology requires that events occur as they would in real life unless you can show that a modification does not affect the outcome. You have not shown this. Even if you prove that there are no repeat sequences of cards; you still have not provided a proof of randomness. Think about it from a logical view. The deck has some large spikes. In looking at every other card; you soften those spikes. But, you will still see manifestations of those spikes.

Something else to look at. You are trying to look at results to see if they still make sense. A poor RNG will result in more stable results than a good RNG. Results that always come out the same prove the RNG is no good. You cannot measure effectiveness in this manner.

There are many ways to speed a BJ sim. But, mucking with the shuffling is very dangerous. You could run years of sims and not realize that you are understating the standard error in every one. For the non-real shuffle sims, I use standard random shuffle techniques.

That's the question I'm asking myself. Obviously, it's not anyone elses job to prove that the technique is "completely invalid"; that's the default assumption unless proven otherwise. But I think the issue is interesting enough to spend some more time on it, regardless of the result. It also seems possible that, even if the algorithm as stated has subtle statistical problems, there may be a similar technique that avoids those problems. (Actually, I already have one in mind -- one that obviates the logic of your "peaks" argument -- but I think that what's learned from examining this one more closely will be useful nonetheless.)

ET Fan has suggested one way to test the validity, which seems reasonable, so I've modified both versions to collect multiple million-round results into CSV files. Do you agree with that approach, or do you believe that there just isn't any way to validate this algorithm?

Yes, it's up to the person altering the basic concept of Monte Carlo techniques to prove that the alteration has no affect. And I'm certain you understand that.

That's the question I'm asking myself. Obviously, it's not anyone elses job to prove that the technique is "completely invalid"; that's the default assumption unless proven otherwise. But I think the issue is interesting enough to spend some more time on it, regardless of the result. It also seems possible that, even if the algorithm as stated has subtle statistical problems, there may be a similar technique that avoids those problems. (Actually, I already have one in mind -- one that obviates the logic of your "peaks" argument -- but I think that what's learned from examining this one more closely will be useful nonetheless.)

Nothing wrong with playing around.

ET Fan has suggested one way to test the validity, which seems reasonable, so I've modified both versions to collect multiple million-round results into CSV files. Do you agree with that approach, or do you believe that there just isn't any way to validate this algorithm?

No that cannot validate it. Comparing results is never a validation of Monte-Carlo simulation. Even if you ran billions of billion round sims and performed an analysis, the analysis would have to be based on some particular stats. The idea of a general simulator is that you can add ANY stats. If you tinker with the shuffling; how can you possibly test for accuracy of a stat you have yet to think of?

Let me give a simple example. Top-Deck Blackjack. This is an obscure BJ rule that gives a bonus for a BJ immediately after the shuffle. OK, suppose you want to know the number of times a Top-Deck BJ occurs two shuffles in a row. Your technique would grossly exaggerate the stat.

But that's just one example. You don't know what other examples are out there. If you want to speed a sim; look at hand resolution, dealing, stat collection, TC calculation (which PowerSim doesn't do correctly,) chip optimization, cover betting simplification, table-driven techniques, cache memory optimization. Look at areas that cannot possibly affect the basic rules of Monte-Carlo simulation. When you mess with shuffling, you mess with the reality of observation. Nothing can be trusted since that is the heart of Monte-Carlo simulation. Such sims are always a point of last resort. The answer is not known. So, how can it be verified if you take short-cuts?

But keep thinking.

regards,
norm

Suppose you have an unusually large number of low cards at the start of the deck. This will force up the count and the bet. You will bet far more during that shoe than usual. Now you "shuffle." But that shuffle keeps half of those low cards at the start of the shoe. You are likley to have two consecutive shoes with large betting. This would affect three CVData features. The Bankroll swing data, the sessioning logic and data and the Betting Strategy by Bankroll feature.

... is that, carried to its logical conclusion, NO computer BJ sim based on a pseudo-random number generator can be considered to be truly "valid," because the pseudo-randomness alters one "basic concept of Monte Carlo techniques." Yet we generally assume that the numbers from a "good" generator are "good enough" to give us useful results, and we don't get too hung up about that. Is there a mathematical definition for "good enough?"

Another problem, it seems to me, is that the real-world game we're modeling uses shuffling techniques that are far less random than a "Knuth shuffle" based on even a poor PRNG. Isn't the justification for using a PRNG-based shuffle (instead of requiring that a "valid" BJ sim must model casino shuffling techniques) that, in the long run, there isn't any statistically significant difference? Again, is there a mathematical definition for "close enough?"

The first part of the issue seems to be fairly straight forward, but see if you can find a flaw in this reasoning: If the set {c1, c2, c3, ... c52} is a random permutation of the 52 cards, then the rearranged set {c2, c4, c6, ... c52, c1, c3, c5, ... c51} is also a random permutation, as is {c3, c6, c9, ...}. Saying otherwise would imply that the original set is not really random.

The second part of the issue is not so easy: is there a correlation between those three sets -- or the other 23 sets, if full the algorithm is implemented as I described it -- that significantly affects a BJ sim?

"Let me give a simple example. Top-Deck Blackjack. This is an obscure BJ rule that gives a bonus for a BJ immediately after the shuffle. OK, suppose you want to know the number of times a Top-Deck BJ occurs two shuffles in a row. Your technique would grossly exaggerate the stat."

I'm not so sure that's true. Yes, if there is a BJ on the first round after a "real" shuffle, then passes 2 and 3 are more likely to produce a BJ on the first hand, but in that same series of "fake" shuffles, when the increment gets to 4 and above, the probability is somewhat reduced (because those particular BJ cards can't be dealt on the first round), so it's not immediately obvious that the number of times a Top-Deck BJ occurs two shuffles in a row, on average, would be "grossly exaggerated." But yes, the general point is valid whether or not that particular example is a good example.

"But that's just one example. You don't know what other examples are out there. If you want to speed a sim; look at hand resolution, dealing, stat collection, TC calculation (which PowerSim doesn't do correctly,) chip optimization, cover betting simplification, table-driven techniques, cache memory optimization. Look at areas that cannot possibly affect the basic rules of Monte-Carlo simulation. When you mess with shuffling, you mess with the reality of observation. Nothing can be trusted since that is the heart of Monte-Carlo simulation. Such sims are always a point of last resort. The answer is not known. So, how can it be verified if you take short-cuts?"

The original idea came up while trying to think of ways to speed up the sim by speeding up the shuffle, but I think it's an interesting question in its own right. And I still think it has some pragmatic value, which is this:

When all is said and done, I believe that the answers to the above questions really depend on what BJ question is being investigated by running a sim. But that question is often just "what's the SCORE of ..." I agree with you that using this shuffle would not be a good idea for "general purpose" BJ simming, but on the other hand, there's no reason that it has to be. In the last modified version of PowerSim that I sent to ET Fan (but haven't yet posted), you can set the "offset limit" to 1, which forces a shuffle on every shoe, so you can do that whenever you're interested in a question that might be affected by the technique. However, if all you're interested in is "how does the score of KO rookie compare to OPP", and you can get a "close enough" answer in 60% of the execution time, then why not?

I would not panic about the cost of the floating point operation or operations. Why? The FP hardware is a completely separate "pipe" in the X86. A good compiler will order/schedule the instructions so that the fp operations are done in parallel with the rest of the instructions inside the loop, and the bottom line is that they might have _zero_ cost associated with them, depending on exactly what is being done inside the loop.

... it's not a matter of panicing, it's a simple matter of testing the shuffle routine with different (not necessarily random) type "shuffles." Beyond a shadow of doubt, 90+% of the shuffle time is taken up by the two FP operations -- and that's with two different AMD processors that have faster FP copros than an Intel.

I believe the reason is that the shuffle (thus all the FP ops) comes all at once. It's a separate pipeline, but it gets "backed up." It would certainly be possible to juggle things so the shuffle gets interspersed with play of the hands, etc., and I expect that would run much faster. But it would make the program much harder to read by third parties.

XBasic isn't a so-called "optimizing compiler," so you have to optimize explicitly yourself. However, I doubt c++, for example, would rearrange things so radically as to reduce the FP cost to zero. Yet, a human optimizer might well accomplish this. There's a lot to be said for staying in control, and knowing what your code is doing at assembly level.

PowerSim isn't optimized for speed at all. Not even a little. As long as you can get a billion rounds in under an hour, I figure readability is a higher priority.

ETF

... is that, carried to its logical conclusion, NO computer BJ sim based on a pseudo-random number generator can be considered to be truly "valid," because the pseudo-randomness alters one "basic concept of Monte Carlo techniques." Yet we generally assume that the numbers from a "good" generator are "good enough" to give us useful results, and we don't get too hung up about that. Is there a mathematical definition for "good enough?"

And this is why I brought up RNGs before. The RNG in PowerSim is inferior to that used by James and me, although it is better than the RNG in SimSimp. However, Monte-Carlo sims by definition are pseudo-random. So a good enough RNG is not invalid. The Die-Hard tests are used to test RNGs.

Another problem, it seems to me, is that the real-world game we're modeling uses shuffling techniques that are far less random than a "Knuth shuffle" based on even a poor PRNG. Isn't the justification for using a PRNG-based shuffle (instead of requiring that a "valid" BJ sim must model casino shuffling techniques) that, in the long run, there isn't any statistically significant difference? Again, is there a mathematical definition for "close enough?"

First I wish people would stop using the name Knuth. Nearly everything he ever said is horridly out of date. I've actually not heard the name in business for over three decades. (Sorry that's just me.) Now on the subject of random versus casino shuffle. First, CVData supports casino shuffles (no matter what BJFO says.) However, two points must be understood. First, extensive testing has shown little difference between most casino shuffles and random shuffles. Second, which casino shuffle would we use? Random is probably better in an overall test than using a particular shuffle. But, when in future we get the speed to an acceptable level; I would expect to always use a set of casino shuffles.

The first part of the issue seems to be fairly straight forward, but see if you can find a flaw in this reasoning: If the set {c1, c2, c3, ... c52} is a random permutation of the 52 cards, then the rearranged set {c2, c4, c6, ... c52, c1, c3, c5, ... c51} is also a random permutation, as is {c3, c6, c9, ...}. Saying otherwise would imply that the original set is not really random.

Correct.

The second part of the issue is not so easy: is there a correlation between those three sets -- or the other 23 sets, if full the algorithm is implemented as I described it -- that significantly affects a BJ sim?

I think te answer is obviously yes. But, even if it were unknown the use would be invalid.

"Let me give a simple example. Top-Deck Blackjack. This is an obscure BJ rule that gives a bonus for a BJ immediately after the shuffle. OK, suppose you want to know the number of times a Top-Deck BJ occurs two shuffles in a row. Your technique would grossly exaggerate the stat."

I'm not so sure that's true. Yes, if there is a BJ on the first round after a "real" shuffle, then passes 2 and 3 are more likely to produce a BJ on the first hand, but in that same series of "fake" shuffles, when the increment gets to 4 and above, the probability is somewhat reduced (because those particular BJ cards can't be dealt on the first round), so it's not immediately obvious that the number of times a Top-Deck BJ occurs two shuffles in a row, on average, would be "grossly exaggerated." But yes, the general point is valid whether or not that particular example is a good example.

Ahh, but you are saying the increment numbers matter. That means the methodology is invalid.

"But that's just one example. You don't know what other examples are out there. If you want to speed a sim; look at hand resolution, dealing, stat collection, TC calculation (which PowerSim doesn't do correctly,) chip optimization, cover betting simplification, table-driven techniques, cache memory optimization. Look at areas that cannot possibly affect the basic rules of Monte-Carlo simulation. When you mess with shuffling, you mess with the reality of observation. Nothing can be trusted since that is the heart of Monte-Carlo simulation. Such sims are always a point of last resort. The answer is not known. So, how can it be verified if you take short-cuts?"

The original idea came up while trying to think of ways to speed up the sim by speeding up the shuffle, but I think it's an interesting question in its own right. And I still think it has some pragmatic value, which is this:

When all is said and done, I believe that the answers to the above questions really depend on what BJ question is being investigated by running a sim. But that question is often just "what's the SCORE of ..." I agree with you that using this shuffle would not be a good idea for "general purpose" BJ simming, but on the other hand, there's no reason that it has to be. In the last modified version of PowerSim that I sent to ET Fan (but haven't yet posted), you can set the "offset limit" to 1, which forces a shuffle on every shoe, so you can do that whenever you're interested in a question that might be affected by the technique. However, if all you're interested in is "how does the score of KO rookie compare to OPP", and you can get a "close enough" answer in 60% of the execution time, then why not?

You simply don't know if you are affecting the outcome. And if you want to get the correct answer (and the correctly calculated SCORE) in a fraction of the time, use CVCX:)

"However, Monte-Carlo sims by definition are pseudo-random. So a good enough RNG is not invalid. The Die-Hard tests are used to test RNGs."

Monte Carlo sims can be based on pseudo-random numbers. But they can also use "quasi-random" numbers -- "low discrepancy" which are not truly random when examined statistically, but which are sufficiently unpredictable (and therefore sufficiently stochastic) to give "valid" results, but which work better for certain Monte Carlo sims because they converge more quickly. And of course they can be based on true random numbers generated by some physical process. So I wouldn't accept the fact that most computer sims typically use PRNGs as implying that that's the general definition of the term. The point of computer Monte Carlo sims using PRNGs is that the numbers don't need to be truly random to give useful results, provided that the PRNG is "good enough" -- which is necessarily a subjective judgement, regardless of the degree of concurrence among experts.

You seem to be saying that if a particular PRNG passes certain statistical tests, then it can be assumed to be valid for use in a BJ sim, but at the same time saying that statistical tests of the algorithm I presented are insufficient to prove that it can also give useful results. But for any specific BJ question being addressed, how do you know that your particular PRNG is or isn't affecting the results?

I believe I do understand your argument, and I actually agree with it -- to a certain extent. However, I think there are some underlying issues that are not quite so simple to dismiss.

First, nearly all simulation is done with PRNGs. Yes there have been other attempts with physical phenom; but they are rare indeed. The tests I'm referring to, Die-Hard, were specifically designed for general purpose RNGs over decades of experience by Marsaglia. This is not the same as cooking up some quick test. They don't look at sequences but look for the difficult to find artifacts that appear in RNGs. For example, create a histogram of a common LCG and it looks random. That's why people thought LCGs were random. Rotate the histogram in three dimensions and you will find dramatically obvious patterns.

But for any specific BJ question being addressed, how do you know that your particular PRNG is or isn't affecting the results?

If it passes the Die-Hard tests it is. If it doesn't or I don't know if it does; why would I take the chance? In any case, a one pass riffle certainly is not. And that's what an increment of 2 is.

Anyone can set up CVData to follow this methodology exactly. Simply define a one-pass riffle, set it to riffle perfectly, set no cut, and set it to randomize the cards every X shuffles depending on the increments you wish to use. These are all standard features of CVData.

Now tell me who's simulator is programmableJ

It's not even "this methodology approximately," and based on my previous experiments, I can predict that the persistent modality of 2 from using a perfect one-pass riffle will not behave in a manner similar to the algorithm I described. Unless your point was that one funky shuffle is about the same as any other (which I certainly don't believe is true), I'm not sure what you were getting at.

Does CVData execute the riffle shuffle on the original deck, as it was before the deal, or does it also simulate the way dealers pick up hands after they are played, and then shuffle that? There's obviously a difference.

I reread it. It looks like the second full pass (really two passes)is the same as a one-pass exact riffle, but not the next pass. Although the next pass (actually four passes) is a two-pass riffle from the original.

Does CVData execute the riffle shuffle on the original deck, as it was before the deal, or does it also simulate the way dealers pick up hands after they are played, and then shuffle that? There's obviously a difference.

Forgot about that. Yes it is in pickup order. Which at least would mix itup a bit.

This algorithm was designed for use in a sim that doesn't really do anything except estimate the long-term IBA, and I still think it's an open question whether any correlation between successive shoes has any effect on that. However, for a sim that does more sophisticated analysis where the correlations could have a noticeable effect, there are many ways to implement similar algorithms which extract unique sequences from each shuffled deck in a less orderly and less predictable way.

for any stat that is affected by consecutive shoes. A prefectly interleaved, one-pass shuffle, with no pick up order disturbance will affect such stats.

This algorithm was designed for use in a sim that doesn't really do anything except estimate the long-term IBA

Well, do we really need more speed for this stat? It's the tricky stats that require tens of billions of rounds.