Arnold Snyder says: I am sponsoring the development of PowerSim blackjack simulation software because I can honestly no longer recommend any of the commercially-available blackjack simulation software. Based on my experience as a blackjack researcher and professional player, the commercial blackjack simulation software available is out-dated. There is no blackjack simulation software available for sale that meets my own needs or that I feel is adequate for meeting the changed needs of today's card counters and other professional blackjack players. Even if you don't understand the changes that are needed in blackjack simulation software, and why they are needed, don't worry, because I do. And you will soon understand too. Better tools will mean more money for card counters and other blackjack players. PowerSim will already run fast, powerful and accurate traditional blackjack and card counting simulations for you that provide the information you need for comparing games and card counting strategies,and calculating risk and bankroll requirements, optimal bets, advantage and win rate for a wide variety of games and rules sets. The open source programmable PowerSim has also already been modified by players to run blackjack simulations that cannot be run on the commercial blackjack simulation software, including simulations of the new and innovative OPP Count for beginning players. But there is a lot more coming. It will take some time, but I intend for the Blackjack PowerSim project to develop exactly the blackjack and card counting simulation software that is needed, 100% free for players. PowerSim blackjack simulation software can be downloaded free by any player.
The Blackjack PowerSim Project: Free Programmable Open Source Blackjack Simulation Software for serious players Free Programmable Open Source Blackjack Simulation Software Free Programmable Open Source Blackjack and Card Counting Simulation Software Professional Blackjack and Card Counting Simulation Software--Free Blackjack and Card Counting Simulation Software Blackjack and Card Counting Open Source Simulation Software Free Professional Blackjack and Card Counting Open Source Simulation Software Free Blackjack and Card Counting Open Source Simulation Software Blackjack and Card Counting Open Source Simulation Software Blackjack and Card Counting Simulation Software  

Powersim Blackjack Simulation Software

Blackjack and Card Counting Open Source Simulation Software
Blackjack and Card Counting Open Source Simulation Software The Beta Release of Blackjack
    PowerSim Simulation Software
    By ET Fan
Blackjack and Card Counting Open Source Simulation Software Download Blackjack PowerSim
    & Instructions
Professional Blackjack and Card Counting Open Source Simulation Software PowerSim: No Compromise on
    By ET Fan
Professional Blackjack and Card Counting Open Source Simulation Software Install XBasic Free
    (For detailed instructions, see the
    Instructions.doc in the Blackjack
    PowerSim download)
Arnold Snyder's Free Winning Blackjack Simulation Software  The Last 0.01%—Indistinguishable
     By ETFan
Blackjack and Card Counting Simulation Software Download XBasic Documentation

Best Blackjack and Card Counting Open Source Simulation Software


POWERSIM Blackjack Simulation Software: No Compromise on Accuracy

By ET Fan
(From Blackjack Forum Vol. XXVI #2, Spring 2006)
© 2006 Blackjack Forum

This article is a response to some questions I've received regarding the accuracy of PowerSim.

Regarding true count calculations, here is a TC calculation straight from the PowerSim source:

BetTC = MAX(-20, MIN(20, XLONG(INT(52! * RC/unSeen))))

The BetTC is the true count that determines which "bin" the results for that round go into. As such, it is restricted to the range -20 to +20. Let's parse the expression from the inner parentheses and move outward:

52! * RC/unSeen

The exclamation mark (!) after 52 makes this a single precision floating point operation, so the FPU coprocessor is called. RC is the current running count. unSeen is the exact number of cards in the shoe that are as yet unseen. 52! * RC/unSeen is the exact full deck adjusted true count to single precision machine limits.

The INT operation floors the result, creating "floored" bins as described in the instruction manual, and as generally agreed is the best procedure. Negative numbers are not truncated; they are floored to the next lowest integer.

The XLONG function changes the data type from floating point to XLONG to correspond with the bin dimension type.

The MAX and MIN functions assure that any result less than -20 becomes -20, and any result over +20 becomes +20, to avoid overlow in the bin[] array.

Lest anyone out there object "Aha! Only to machine limits!", the accuracy of the FPU is more than adequate to return the correct answer in every case for 1, 2 ... 10 decks. Probably to 100 decks, though we haven't tried it. For those with XBasic installed, here is a very simple program you can cut and paste to test this assertion:


RC = XLONG(INLINE$("Input Running Count: "))
unSeen = XLONG(INLINE$("Input unseen cards [0 to exit]: "))
BetTC = MAX(-20, MIN(20, XLONG(INT(52! * RC/unSeen))))
PRINT 52! * RC/unSeen, INT(52! * RC/unSeen), BetTC
GOTO Start


Whatever you input for Running Count or unseen cards, if it's anything that could conceivably happen in 1-10 decks, it will give the right answer. For example, if you input -12 for your running count, and 104 for unseen, the true count returned is -6. Change the unseen to 105, it's still -6. Change unseen to 103, TC becomes -7. (-6.05825 is floored to -7)

Here is another example of a TC calculation, this time from the split decision subroutine:

IF 52! * RC/unSeen >= SplIndex[N, Upcard] THEN Ans = 1

When Ans = 1, that means a split will take place in the main body of the program. There is no need to take the INTeger, in this case, because if INT(52! * RC/unSeen) is greater than the split index (which is always an integer) it follows that 52! * RC/unSeen is also greater than or equal to the split index, since a floored index is alway less than or equal to the exact fractional index.

Anyone with any interest can download the PowerSim package. The source is in the file PowerSim.x. You can read it with WordPad or Word for Windows. All the TC conversions are toward the end in the BetDecision, HitDecision, DblDecision, SurDecision, SplDecision, InsDecision and ESDecision subroutines. They are all precisely analogous to the calculations above.

PowerSim doesn't normally do nearest half-deck estimates in the true count conversion, as was done for some of the simulations in Chapter 10 of BJA3. In point of fact, while rounding to the nearest half-deck, or quarter-deck, may be one way to approximate likely errors by some players, it is clearly less accurate than the exact method used in PowerSim as outlined above.

The method of TC calculation (ie. the nearest half-deck, nearest quarter-deck, exact, etc.) does make a small difference in SCORE. But in no way should that be interpreted as an admission that the exact calculation, as used by default in PowerSim, is the even the tiniest "bit off."

Regarding Risk of Ruin

The formula used for RoR in PowerSim is the formula that appears in Blackjack Attack edition 3 (BJA3) pg. 113. It was used to create the six pages of tables that follow in the book. Here is the code from ScoCalc.x that does this calculation:

ror[p] = 1
rExp! = -2! * exp[p] * bankRoll / var[p]
IF rExp! < -87 && exp[p] > 0 THEN ror[p] = 0
IF exp[p] > 0 && rExp! >= -87 THEN ror[p] = EXP(rExp!)
PRINT " ROR ="; ror[p];: IF ror[p] = 1 PRINT "00%!!": ELSE PRINT

The EXP function takes the mathematical constant e = 2.7182818... to the power of the argument -- in this case rExp!, which is -2 x the expectation of the player x the bankroll divided by the variance of the player. There is also some bounds checking in this code to prevent a halt with underflow if rExp! is less than -87. Although other formulas for RoR are possible, to the best of our knowledge this is, or should be, the formula most consistent with the SCORE methodology.

Optimal Betting Calculations

The PowerSim optimal betting calculations exactly follow one of the procedures recommended in the seminal paper by Dr. Brett Harris, "The Theory of Optimal Betting Spreads." Here is a link to that paper: The Theory of Optimal Betting Spreads. It is well known that there are shorter ways to do this, but not more accurate methods. The calculation is completely contained in the ScoCalc.x source code, which is relatively short.

Better yet, if anyone who has ever written an optimal betting calculation routine based on the RoR formulae in Blackjack Attack would post a set of TCs with frequencies, win rates, and standard deviations and/or variances, we will calculate optimal ramps directly with ScoCalc and compare our results with yours. PowerSim calculates exact fractional bets to single precision machine limits. It would be trivial to switch to double precision floating point arithmetic -- trivial and pointless. No simulation is going to provide accuracy beyond six or seven decimal digits.

ScoCalc does not automatically calculate optimal Wong-in/Wong-out points, but this is not an accuracy issue. The optimal bets output are optimal for the given "hard bet" inputs, as explained in the instructions. The user may have to try two or three Wong points to find the one that returns the best SCORE. This system was deliberately chosen in PowerSim, because with this system the user is not forced into one particular Wonging scheme.

Additionally, PowerSim does not calculate optimal integer bets, or with the unit size calculated to two decimal places as per BJA3 pg. 211. But it is less accurate to round to two decimals when full machine accuracy is available. Again from pg. 211: "Two types of betting schemes were employed. The first is optimal betting. It permits fractional units ..." [emphasis added]

Since BJA3 presents "practical" betting schemes right next to the optimal schemes, no purpose is served in making the optimal bets less optimal (or more practical) by rounding them in any way. If the object is to find an accurate SCORE, then fractional bets must be allowed. If fractional bets are allowed, it's pointless to round to two decimals.

Yet throughout the charts in Chapter 10 of BJA3, there are many RoRs in the rows designated for optimal betting slightly different from 13.5%. ET Fan has personally tried over one hundred bet spreads, including many straight from the pages of BJA3, and the optimal bets produced by PowerSim render the precise RoR required by the theory underlying SCORE to 6 digits. Namely, e^(-2), or 0.135335.

I am not complaining about any inaccuracy in the methods employed to create the charts in BJA3. I simply point out that PowerSim produces results closer to what BJA3 says is the way SCORE should work than the results that actually appear in Chapter 10 of BJA3...

Regarding SCORE

According to BJA3, pg. 155 "Of course, we know the risk of ruin ahead of time: It will always be 13.5%." This is e^(-2) rounded off to three decimals, and PowerSim consistently produces results actually closer to the stated ideal than those reported in BJA3.

Here is the formula used to calculate SCORE in ScoCalc:

IF exp[p] >= 0 score[p] = exp[p] * exp[p] / var[p] * 1000000

Regarding Random Number Generators

I would encourage people to look at the writings of expert Donald Knuth on the subject of Random Number Generators (RNGs). (The latest edition of volume 2 of "The Art of Computer Programming," containing 180 universally acclaimed pages on RNGs, appeared in November of 1997.) George Marsaglia, creator of the famous diehard series of RNG tests, has this to say on Random Number Generators (from a 2003 unsenet post):

It doesn't seem reasonable to consider that there is a best. Just as the `Miss America Contest' judges have to view talent, swim suit, evening gown and interview scores before voting, for RNG's one should consider test results, speed, simplicity, period length, size and possibly other factors, depending on the application. (My own judging tends to give extra weight to the equivalent of the swim-suit competition---beauty of the underlying theory.)

Powersim Handling of 6:5 Blackjack Simulation

I also received questions regarding whether my advice on handling 6:5 blackjack sims would invalidate any SD calculations. Here is my advice on using PowerSim for 6:5 games, from the PowerSim project board on

"You know +16 is the most a player can win on a given round. So just have the program pay off +17 for an untied blackjack, then have ScoCalc check that bin (which would be bin[P, TC, 17+25]) and make the result! = 1.2"

In a follow up post I explained:

"Right after the line: result! = .5!*(res - 25), in the DiskOutput subroutine, just add the line:

IF res = 42 THEN result! = 1.2 ... Same patch should work in ScoCalc in the main routine."

As you can see, the result goes in as +1.2, which is the exactly correct result for this payoff. This +1.2 is what goes into the win rate and variance calculations. The standard deviation is the square root of the variance. Again, the variance calculations appear in the ScoCalc.x source code, and the source is open for all to inspect. To the best of my knowledge, it's 100% correct.


We are all in favor of free enterprise, and there are many excellent programmers writing blackjack software all over the world today. If it weren't for the inherent limitations in a closed-source program, any good commercial sim program might be worth three or four PowerSims in its current rendition.

But commercial programs are almost always closed-sourced, and opening up the source markedly increases the value of a program, even for users with no interest in tinkering with the source code. Since the cost of PowerSim is zero, and since it runs valuable blackjack simulations, its value/cost ratio is literally infinite.

I would like to point out that the open nature of the PowerSim project has already led to improvements and new discoveries by inventive users. And there will continue to be improvements and changes to PowerSim. Thatís why itís open-source. There's more than one way to skin a cat, and there's more than one valid, accurate algorithm.

Another Tool To Ensure Accuracy

Besides the calculation of statistics from raw data, another area of potential problems in a blackjack simulation program is in the play of the hands. We have included, in version 4 of PowerSim, a tool to help users detect any possible inconsistency in payoffs, or in the play of the hands. It is a patch that allows users to input any hand(s), any upcard and holecard (if ENHC is not in effect), any running count and penetration, and any hits as required to observe the results. The program makes all playing decisions, based on the current count, and the chosen strategy file.

It is called PSDebug, and the lines added to create it are all clearly marked in the source code with the comment 'debug. You can use the XBasic search function and find them very quickly. Version 4 of PowerSim is this exact same program with all the 'debug lines deleted. Just another way to put computer power in the hands of the people.

I'd take it as a great favor if you would use PSDebug to try any rule combination you can think of -- especially rules that include ENHC. Do your best to trip it up. It's actually kind of fun! See if you can find any combination of hands that result in an incorrect payoff. If you find anything, please inform us immediately. If you desire, your name or handle will be immortalized in the PowerSim source code. ♠

ET Fan

Return to Blackjack Forum Online Home

Return to the Blackjack Forum Professional Gambling Library

© 2004-2005 Blackjack Forum Online, All Rights Reserved
  Blackjack and Card Counting Open Source Simulation Software The Beta Release of Blackjack PowerSim
    Blackjack Simulation Software