(Sorry for weirdly long delay in reply; I've been on "completely disconnected" vacation, which I highly recommend.
)
I'm still not sure what picture this is intended to paint. Cacarulo states, "Actually, I’m aware of the accumulated rounding errors that occur with double precision. When testing with 13 or more decimals, the sum stops being zero
precisely due to precision issues" (my emphasis added). This simply doesn't follow. That is, if P is the proposition "the sum* of EORs is zero when rounded to D=12 decimal digits" and Q is the proposition "the EVs reported by our CA are accurate to D digits", then the claim seems to be that P implies Q. This is untrue...
despite the fact that Q happens to be true in this particular case.
(*) As an aside, it's a bit odd to perform this test by computing the *sum* of EORs, which is only even sensible when distinguishing the 10-valued ranks as you've done above. The units of the sum are "1300 times the initial wager." The *average* EOR makes more sense, preserving the same units as the EV, and you can verify suggests 13 digits of accuracy instead of 12, which is the actual correct value.
Cacarulo also states, "I'm confident that this wouldn't happen with arbitrary precision, and on that, we completely agree." My point here is that confidence in the accuracy of our CA doesn't logically rest on the output of this exercise, on the picture you've painted in the table above.
To demonstrate this point, let's look at another example. Consider the same rules (6D, S17, DOA, DAS, SPL3, LS), but played using full-shoe CDZ- strategy. Let's "test" another CA using the same procedure you've executed above:
Code:
E[X] = -0.33051231489072685
EOR[A] = -0.09346291873071691
EOR[2] = 0.06907495555899118
EOR[3] = 0.081964864492504313
EOR[4] = 0.11154206154045318
EOR[5] = 0.14201417819121528
EOR[6] = 0.074232005629511211
EOR[7] = 0.039193443497114594
EOR[8] = -0.011707823381252452
EOR[9] = -0.042290678394506231
EOR[T] = -0.092636511499340907
(Note that there is no need to iteratively re-display the same values with decreasing number of digits of precision. The 17 digits above unambiguously specify the underlying 64 bits of the double-precision values involved, if you want to verify calculations yourself.)
The average of these EORs is about 0.00000108, which would suggest, exactly as you've suggested above, that this CA's values are accurate to 5 decimal digits... and any inaccuracy beyond those 5 digits "are due precisely to precision issues," and *only* to precision issues. Looking at this another way, we can compute the "average expected return" (i.e., averaged over each possible single-card removal) as E[E[X]] = -0.3305112347056537, which also agrees with the full-shoe EV above to 5 digits.
But our "confidence" in the accuracy of those leading 5 digits is not justified by this experiment. This CA's values reported above are *not* accurate even to 5 decimal digits; they are only accurate to 4. These results are from the old v5.2 of my CA, from over two decades ago, where I *knew* my resplit algorithm was an approximation, a tradeoff of accuracy for speed of execution. You can verify this inaccuracy checking against the exact EV of
-636491186124390779995774550739146028101753/192719583540554771243108474049609438884038125
obtained from my CA's latest v7.6, of using k_c's CA, or MGP's (at least for full non-depleted shoes), all of which can evaluate CDZ- strategy.
In short, "average EOR==0 to D digits" doesn't imply "D digits of accuracy." In other words, given a non-zero average EOR, I don't know how to "separate" the contributions to that error from (a) cumulative rounding errors of limited double precision vs. (b) algorithmic flaws, bugs, approximations, whatever you want to call them, that result in the value being computed not being expressible as an average, over all n! permutations of the shuffled shoe, of a random variable mapping a prefix of that arranged shoe to an outcome of the round (so that the "extended true count theorem" would apply).
Originally Posted by Cacarulo
Reply With Quote
Bookmarks