| Blackjack Forum | Poker Tournaments |
|
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
POWERSIM: NO COMPROMISE ON ACCURACY |
||||||||||||||||||||||||||||
FROM ET FAN: 
Best Casino Bonuses Online |
POWERSIM: 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 issues raised by Norm Wattenberger regarding the accuracy of PowerSim. Mr. Wattenberger was informed that his charges were incorrect, and was given ample opportunity to respond. He replied with more accusations. We are also appealing to the public at large. Any reasonable person who can shed light on the accuracy issues raised by Wattenberger, or my responses here, please post your comments on blackjackforumonline. If you would prefer not to comment in a public forum, please feel free to contact ET Fan privately via email. Your confidentiality will be respected. Please restrict your remarks to the accuracy issue. Comments on structure and programming style will have to wait for another day. And so, ladies and gentlemen of the jury! We will lay the facts before you for your careful consideration. It is our contention that Mr.Wattenberger's assertions concerning accuracy are not legitimate. We shall solicit expert testimony from all quarters to shed light on these matters. Wattenberger also made a statement unrelated to accuracy that is highly suspect. Nevertheless, we concede that PowerSim is a work in progress. If the court determines there is even one valid concern regarding accuracy, we are willing, nay eager, to hear any such concerns and address them forthwith. Exhibit One Here is a portion of a recent exchange between Wattenberger and ETFan on the green chip board of bj21.com. The small portion below clearly falls within the fair use copyright provision: Wattenberger: "PowerSim does not correctly calculate SCORE, optimal bets, RoR or even True Counts..." ETF: "Yes it does..." Wattenberger: "First, no you do not calculate any of these correctly... " "... It is the careless attitude toward accuracy. Your TC calculations are sort of close. Your comment is that they are only a bit off. Your optimal betting calculations are sort of close. SCORE is sort of close. The RNG is at least better than the first. But you rejected the best one. Your advice on how to handle 6:5 BJ would make SD calculations incorrect. Everything is a compromise." Well, we agree on one thing, Mr. Wattenberger. Everything in life tends to involve some compromise. All simulation is in fact a compromise based on our limits as mortal beings to do perfect and complete combinatorial analysis. But on the issue of accuracy in the calculations from raw data, there is virtually no compromise in PowerSim. We shall now examine each one of these accusations, and outline the PowerSim procedures in detail. Comments or corrections from any expert are most welcome. Testimony and Cross Examination Wattenberger's first statement: "Your TC calculations are sort of close." Response: 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. I heard someone in the jury say "Aha! Only to machine limits!" Sorry -- no cigar. 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: FUNCTION Entry () Start: RC = XLONG(INLINE$("Input Running Count: ")) unSeen = XLONG(INLINE$("Input unseen cards [0 to exit]: ")) IF unSeen = 0 THEN EXIT FUNCTION BetTC = MAX(-20, MIN(20, XLONG(INT(52! * RC/unSeen)))) PRINT 52! * RC/unSeen, INT(52! * RC/unSeen), BetTC GOTO Start END FUNCTION 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) MathProf ... T-Hopper ... Grosjean ... anybody who has ever written a true count conversion routine -- we solicit your expert testimony: What is "sort of close" about this calculation?? 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. Again, if any expert can find a mistake here, step up now and point it out. 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. Please point out any inaccuracy anywhere. Wattenberger, whose accusations have remained so vague that it is difficult to respond with facts, may be talking about the fact 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. But that is not what he says. He says the calculation is "sort of close," which to many readers may imply “inaccurate.” 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. Furthermore, Wattenberger states that exact true count calculations are an option in his software. If that's the case, is he saying that his software’s results with the exact true count option turned on are inaccurate (or “sort of close”), or are they essentially the same as the PowerSim method? At this point, there appears to be no third option. Wattenberger comment #2: "Your comment is that they [meaning PowerSim's true count calculations] are only a bit off." Response: ET Fan never made any such comment. He did state that the method of TC calculation (ie. the nearest half-deck, nearest quarter-deck, exact, etc.) only makes a small difference in SCORE. 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." Wattenberger comment #3: "PowerSim does not correctly calculate ... RoR ..." Response: 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 used by Wattenberger's software as consistent with the SCORE methodology. The preeminent blackjack scholar who uses the handle "MathProf" was asked about this, and he testifies he'd be surprised if they used another formula. Again, if there has been any mistake in realizing this formula, we welcome rebuttal. Wattenberger comment #4: "Your optimal betting calculations are sort of close." Response: 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 this is not the issue. The issue is accuracy. The calculation is completely contained in the ScoCalc.x source code, which is relatively short. We believe it is correct, but again, we openly provide the source, free of charge, so that anyone can promptly inform the court of any error. 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. The defendant may be reacting to the fact that ScoCalc doesn't automatically calculate optimal Wong-in/Wong-out points. Again, 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. Or, possibly the defendant may be objecting that 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 prepared by Wattenberger's software, 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. Mr. Wattenberger's software is not on trial today. We are not complaining about any inaccuracy in the methods employed to create the charts in BJA3. We would simply ask the jury to determine how it's possible PowerSim's "sort of close" methods can produce results closer to what BJA3 says is the way SCORE should work than the results prepared by Mr. Wattenberger's software that appear in Chapter 10 of BJA3.. Wattenberger comment #5: "SCORE [in PowerSim] is sort of close." Response: 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. Again we ask, if the PowerSim method is only "sort of close," why does it consistently produce results 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 To the best of our knowledge, Wattenberger has not yet raised any objection to the calculations in PowerSim of the expectation (exp[p]) or variance (var[p]) of player number p. Assuming those are correct, what is wrong with this calculation? For that matter, we are wide open to any criticism of the calculations of exp[p] or var[p]. We are wide open to everything. Our source is wide open. Wattenberger comment #6: "The RNG [in PowerSim] is at least better than the first. But you rejected the best one." Response: This is not related to the accuracy issue, since "better" and "best" are subjective terms representing the personal opinion of the defendant, Mr. Wattenberger. Defendant has elected to reject anything written by the expert Donald Knuth on the subject of Random Number Generators (RNGs), since he's "not heard the name in business for over three decades." (For the record, the latest edition of volume 2 of "The Art of Computer Programming," containing 180 universally acclaimed pages on RNGs, appeared in November of 1997.) However, he writes admiringly of George Marsaglia, creator of the famous diehard series of RNG tests, so we thought the jury might be interested in what Mr. Marsaglia has to say on this subject (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.)" And specifically on the Mersenne Twister: "The Mersenne Twister rates highly in test results and period-length, but poorly in simplicity and swim-suit, (beauty of underlying theory). C versions I have seen take several dozens of statements." The Mersenne Twister is the RNG Wattenberger uses. We won't pass judgement here on the defendant's taste in swim suits. Wattenberger comment #7: "Your advice on how to handle 6:5 BJ would make SD calculations incorrect." Response: Here is the advice given by ET Fan, from the PowerSim project board on www.blackjackforumonline.com: "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 he further 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." Would any expert please explain how this invalidates any SD calculations? 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. The source is open for all to inspect. To the best of our belief, it's 100% correct. Please examine it carefully. Show the jury where there's any error. Wattenberger comment #8: "Everything is a compromise." Response: The word "everything" makes this a vast overstatement. Certainly, compromise is one of the secrets to a happy and productive life. But when it comes to accuracy in the calculation of simulation statistics, it seems there is little need for compromise. Summation: We are all in favor of free enterprise. We would encourage anyone so inclined, to run out and buy Mr. Wattenberger's fine suite of programs, even though there is now a free alternative that is superior in some respects called PowerSim. In fact, 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. We won't dwell any more on the frivolous charges by Mr. Wattenberger. (Any really cheap lawyers in the house? ;-D) We will simply observe 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. ♠ Sincerely, ET Fan etfan21@hotmail.com Return to Blackjack Forum Online Home Return to the Blackjack Forum Professional Gambling Library |
|||||||||||||||||||||||||||
| © 2004-2005 Blackjack Forum Online, All Rights Reserved | |||||||||||||||
|
|
 The Beta Release of Blackjack PowerSimBlackjack Simulation Software |
||||||||||||||
