Software update with new split EVs

[k_c]

Hmmm. Thanks for running this, because I get slightly different results, so the more sanity checking, the better. I can reproduce your results for SPL1 and SPL2, but for SPL3 I get an EV for splitting of 247/198 = 1.247474. I get this value both with my strategy.exe calculator, where it is "actually" analyzing blackjack, as well as with my faked-up Mathematica implementation of the no-hit showdown game that I described earlier.

Following is my breakdown of the splitting outcomes for each of the 27,720 arrangements of the cards in the shoe (after removing the initial pair and dealer up card):

p_-4 = 25/27720 = 0.000901876
p_-3 = 280/27720 = 0.010101
p_-2 = 1660/27720 = 0.0598846
p_-1 = 1680/27720 = 0.0606061
p_0 = 5105/27720 = 0.184163
p_1 = 4930/27720 = 0.17785
p_2 = 8764/27720 = 0.316162
p_3 = 3042/27720 = 0.10974
p_4 = 2234/27720 = 0.0805916

I'm not sure where the problem is yet. I am assuming that the player always resplits whenever possible; maybe that is the cause of the difference? If it is helpful for comparison, I can pm a zipfile with the actual shoe arrangements and my itemization of the outcomes.

Is this the shoe comp you want to compute?

 

[MGP]

If you really want the fastest splits besides T Hoppers, I believe mine will win. I don't know how to isolate it though.

Eric, you could probably easily modify your program to handle it though. All you need to do is for any hand that is actually possible, calculate the probs for any shoe with up to 4 paircards missing. Anything that has multiples of any card can be re-used, e.g. 22457 can be used for the original shoe and a -P for paircard 2.

I don't know if it's worth your time though. I'm convinced though that my method will beat any recursive method.

 

[ericfarmer]

Is this the shoe comp you want to compute?

Yes. Your split value agrees with mine; I suspect that the difference iCountNTrack is seeing is due to the fact that he makes an optimal decision whether to resplit or not, where I/we resplit at every opportunity. But I have not verified this yet.

 

[ericfarmer]

If you really want the fastest splits besides T Hoppers, I believe mine will win. I don't know how to isolate it though.

I may be misunderstanding which segment of the algorithm you are measuring. When I click "Calculate Now!" in your CA, the time until results are available is about 12 times longer than my corresponding time. As you point out, though, the challenge is isolating a particular component of the calculation. Splits are particularly difficult for me to isolate; read on...

Eric, you could probably easily modify your program to handle it though. All you need to do is for any hand that is actually possible, calculate the probs for any shoe with up to 4 paircards missing. Anything that has multiples of any card can be re-used, e.g. 22457 can be used for the original shoe and a -P for paircard 2.

I don't know if it's worth your time though. I'm convinced though that my method will beat any recursive method.

I think what you describe is actually exactly what my code currently does. That is, I compute the set of all possible hands that either (1) total 21 or less, or (2) total 21 or less after an appropriate number of pair cards have been removed. This enumeration happens up front, and doesn't take long. I then compute the dealer probabilities of outcomes for each of those hands; this takes 99+% of the execution time. Finally, I computing E(stand), E(hit), E(double), and E(split), all of which are down in the noise compared to the dealer probs.

But saying that my E(split) calculation is fast isn't really fair, though, since it depends on all of those dealer probability calculations, in an intimate way that can't really be separated from the rest of the calculations.

My E(split) calculation could still be made faster, though, by caching values of EV(X;a,b) and EV(N;a,b). I waste a lot of recomputation of these values since I compute them recursively via the simple recurrences in my paper. But I am not yet convinced it's worth it, since it's such a ridiculously small fraction of the overall execution time.

But I can be convinced otherwise; as before, I would certainly be interested in more timing analysis, especially if others (including T Hopper?) can provide implementations to test, too.

 

[k_c]

Yes. Your split value agrees with mine; I suspect that the difference iCountNTrack is seeing is due to the fact that he makes an optimal decision whether to resplit or not, where I/we resplit at every opportunity. But I have not verified this yet.

I don't know if this will help but one my old programs could compute any number of splits for a fixed strategy. It wasn't very efficient and could only handle 1 player hand versus one dealer up card at a time. Below composition has already removed 2 9s and 1 8 to account for hand of 9-9 v 8 dealt from a starting composition of 0,0,0,0,0,0,0,5,5,5 (1-10).

Unless I'm missing something, which is possible(!), the only strategy is if you draw another pair card, split. If you draw anything else, stand. This is right for a fixed strategy and in this case also happens to be optimal. The most split hands possible are 5 (4 splits) because of the limited number of 9s remaining.


Number of Decks: 2
Shoe comp: (1) 0 (2) 0 (3) 0 (4) 0 (5) 0
(6) 0 (7) 0 (8) 4 (9) 3 (T) 5
Computing optimal EVs for an individual hand (shown below)....
Double Rule: Double on any total, 2 cards only
Dealer stands on soft 17
Hole card rule: None (American rules)
No surrender allowed
Number of allowed splits (Aces): 1
Number of allowed splits (2 - 10): 9
DAS
Player is allowed one card to split ace
Optimal strategy (split strat is fixed optimally on first split hand)
Dealer up card: 8
Player Hand: 9,9....computing....please wait
Player Stand EV: 0.5833333333
Player Hit EV: -1
Double EV on 18: -2
Split[1]: 0.9848484848
Split[2]: 1.166161616
Split[3]: 1.247474747
Split[4]: 1.275757576
Split[5]: 1.275757576
Split[6]: 1.275757576
Split[7]: 1.275757576
Split[8]: 1.275757576
Split[9]: 1.275757576
2 card doubles: None

 

[MGP]

I think what you describe is actually exactly what my code currently does. That is, I compute the set of all possible hands that either (1) total 21 or less, or (2) total 21 or less after an appropriate number of pair cards have been removed. This enumeration happens up front, and doesn't take long. I then compute the dealer probabilities of outcomes for each of those hands; this takes 99+% of the execution time. Finally, I computing E(stand), E(hit), E(double), and E(split), all of which are down in the noise compared to the dealer probs.

But saying that my E(split) calculation is fast isn't really fair, though, since it depends on all of those dealer probability calculations, in an intimate way that can't really be separated from the rest of the calculations.

If you're not including this time then all split calcs are trivial with respect to time and any comparisons are meaningless.

The only thing that matters is how many dealer probs are needed. With any recursive method, you are calculating not only the dealer probs for EV(x)'s but also for EV(N)'s. That's a waste of time since you're doing 9 extra calcs for every EV(N). The thing to realize is that EV(N)'s can be calculated directly from the EV(x)'s saving 9 calcs for every hand.

The other thing is once you figure out which hands are used for CD play as long as you're using CDZ or less (e.g. 2C or TD) then you only need to calc probs for hands that are used in CD play.

Finally, I was saying you reuse the dealer probs based on the shoe state. So for the example of 22457 vs UC - you use the same probs for a (22457 = 20) for EV(x) and (2457 = 18) for EX(x-P). You just use the compare the different totals without calculating the probs for a shoe state of (Shoe minus two 2's, a 4, a 5, a 7, and the UC).

My E(split) calculation could still be made faster, though, by caching values of EV(X;a,b) and EV(N;a,b). I waste a lot of recomputation of these values since I compute them recursively via the simple recurrences in my paper. But I am not yet convinced it's worth it, since it's such a ridiculously small fraction of the overall execution time.

Of course you should cache them Just so you can reference them later if you need.

 

[ericfarmer]

The only thing that matters is how many dealer probs are needed. With any recursive method, you are calculating not only the dealer probs for EV(x)'s but also for EV(N)'s. That's a waste of time since you're doing 9 extra calcs for every EV(N). The thing to realize is that EV(N)'s can be calculated directly from the EV(x)'s saving 9 calcs for every hand.

It is not true that "with any recursive method, you are calculating not only the dealer probs for EV(X)'s but also for EV(N)'s." I think I have confused things a bit by using a combination of approaches, the first being a "linear" computation of dealer probabilities for each hand subset (see below), and the second being the recursive computing of the necessary EV(X)s and EV(N)s. The details of this are in my write-up referenced earlier, but the important point is that the former step does not involve any conditioning on non-pair card removals, and the latter recursive step does not require recomputing any dealer probabilities at all.

The other thing is once you figure out which hands are used for CD play as long as you're using CDZ or less (e.g. 2C or TD) then you only need to calc probs for hands that are used in CD play.

This is something I recall discussing on bjmath.com. If I understand you correctly, the idea is that, for example, rather than addressing all 3072 possible subsets of cards in a player hand, only consider those that would actually be reached via the specified playing strategy. (For an extreme example, if the player strategy is to always stand, then we only need to consider 55 hands instead of all 3072.) Is this what you mean? Granted, this is something that I do not do; it takes just as long for me to evaluate an "always stand" strategy as it does CDZ-.

Finally, I was saying you reuse the dealer probs based on the shoe state. So for the example of 22457 vs UC - you use the same probs for a (22457 = 20) for EV(x) and (2457 = 18) for EX(x-P). You just use the compare the different totals without calculating the probs for a shoe state of (Shoe minus two 2's, a 4, a 5, a 7, and the UC).

I think we are in violent agreement here; this is exactly the "linear" step mentioned above. I enumerate the hand subsets that total 21, or may total 21 with some number of pair cards removed. Then, one time, I compute the dealer probabilities for each of those hands.

The only time that I return to those probabilities repeatedly for a given subset is when recomputing E(stand) as a different plus/minus summation of those probabilities, treating the subset as different hands based on removing different numbers of pair cards.

 

[ericfarmer]

I dont quite understand your setup, are you calculating split EVs using optimal post-split strategies. I use optimal post-split EVs.
This is a download link for the program, you can tinker with it if you would like

http://code.google.com/p/blackjack-combinatorial-analyzer/downloads/list

I finally had a chance to brute-force this making optimal decisions of whether to re-split (as opposed to always re-splitting at every opportunity, which is the assumption in my CA).

Unfortunately, I still get a split EV of 1.2474... That is, it is in fact optimal to always re-split at every opportunity. So I am not sure of the cause of the differences. But it looks like four different approaches all yield this same answer: my CA, my brute force evaluation in Mathematica, and k_c's CA and his old code as well.

Hmmm...

 

[iCountNTrack]

I finally had a chance to brute-force this making optimal decisions of whether to re-split (as opposed to always re-splitting at every opportunity, which is the assumption in my CA).

Unfortunately, I still get a split EV of 1.2474... That is, it is in fact optimal to always re-split at every opportunity. So I am not sure of the cause of the differences. But it looks like four different approaches all yield this same answer: my CA, my brute force evaluation in Mathematica, and k_c's CA and his old code as well.

Hmmm...

I got so hooked all night last night (slept for one hour) trying to figure out what is wrong, especially that 4 independent methods all match and dont match my results. I was not able to see where the problem, maybe we need to look at some intermediate results and take it from there. I thought we can look at the number and compositions of the rounds for all 4 split hands. I get 196. see attached excel file for compositions of each split hand. Please let me know thanks.

 

[ericfarmer]

I got so hooked all night last night (slept for one hour) trying to figure out what is wrong, especially that 4 independent methods all match and dont match my results. I was not able to see where the problem, maybe we need to look at some intermediate results and take it from there. I thought we can look at the number and compositions of the rounds for all 4 split hands. I get 196. see attached excel file for compositions of each split hand. Please let me know thanks.

I know the feeling, I would like to understand what is happening here as well. The attachment looks right to me, although there are some duplicates; for example, rows 3 and 36 (counting the header row) are identical, both with three 9-8 hands. Maybe this is key? Anyway, boiling these duplicates down, in total we both see 60 distinct 4-tuples of hands.

Let me know if there is a convenient format in which I can provide any of my data for comparison.

 

[iCountNTrack]

I know the feeling, I would like to understand what is happening here as well. The attachment looks right to me, although there are some duplicates; for example, rows 3 and 36 (counting the header row) are identical, both with three 9-8 hands. Maybe this is key? Anyway, boiling these duplicates down, in total we both see 60 distinct 4-tuples of hands.

Let me know if there is a convenient format in which I can provide any of my data for comparison.

The reason you get duplicates is because there are different ways that this round can be dealt for example, for example for three 9-8 hands,

One way:

You get 9-9 on your initial hand, you split, you have a 9 on first split hand and a 9 on second split hand.
You play the first split hand you get an 8, you stand on the first split hand (which now has 9-8).
You play second split hand, you get a 9. you have 9-9 you resplit, now you have a 9 on second split hand, and a 9 on third split hand.
You play second split hand you get an 8, you stand on second split hand (which now has a 9-8),
You play third split hand you get an 8, you stand on third split hand (which now has 9-8)
You have three hands of 9-8.

Second way:

You get 9-9 on your initial hand, you split, you have a 9 on first split hand and a 9 on second split hand.
You play the first split hand you get an 9, you resplit the first split hand, now you have a 9 on first split hand, a 9 on second split hand and a 9 on third split hand.
You play first split hand, you get a 8. you stand on first split hand (which now has 9-8)
You play second split hand, you get a 8. you stand on second split hand (which now has 9-8),
You play third split hand you get an 8, you stand on third split hand (which now has 9-8)
You have three hands of 9-8.

Dealing ordered sequences will generate a unique card sequence for non-split hands but will generate sequences with multiplicity for split hands. Dealing ordered is a royal pain but it mimics as closely as possible the way a round of blackjack is dealt

 

[ericfarmer]

The reason you get duplicates is because there are different ways that this round can be dealt for example, for example for three 9-8 hands,

One way:

You get 9-9 on your initial hand, you split, you have a 9 on first split hand and a 9 on second split hand.
You play the first split hand you get an 8, you stand on the first split hand (which now has 9-8).
You play second split hand, you get a 9. you have 9-9 you resplit, now you have a 9 on second split hand, and a 9 on third split hand.
You play second split hand you get an 8, you stand on second split hand (which now has a 9-8),
You play third split hand you get an 8, you stand on third split hand (which now has 9-8)
You have three hands of 9-8.

Second way:

You get 9-9 on your initial hand, you split, you have a 9 on first split hand and a 9 on second split hand.
You play the first split hand you get an 9, you resplit the first split hand, now you have a 9 on first split hand, a 9 on second split hand and a 9 on third split hand.
You play first split hand, you get a 8. you stand on first split hand (which now has 9-8)
You play second split hand, you get a 8. you stand on second split hand (which now has 9-8),
You play third split hand you get an 8, you stand on third split hand (which now has 9-8)
You have three hands of 9-8.

Dealing ordered sequences will generate a unique card sequence for non-split hands but will generate sequences with multiplicity for split hands. Dealing ordered is a royal pain but it mimics as closely as possible the way a round of blackjack is dealt

Ah, now we're getting somewhere. If I understand correctly, each row in your Excel spreadsheet corresponds to a unique ordered "prefix" of cards in the shoe that yields the indicated 2, 3, or 4-tuple of split hands. Counting this same way, I get 212 distinct "pre-dealer" playouts, not 196.

We agree on all of the 4 two-hand splits and the 16 three-hand splits. But I get more possibilities for four hands. For a specific example, you list 3 instances of the case (9-8, 9-8, 9-8, 9-8), where I see 5 of these. We can count these in two different ways:

First, we can predict how many we should see as described here (http://sites.google.com/site/erfarmer/downloads/blackjack_split.pdf) with the following formula:

Sum[(1 - k / (n - 1)) * Binomial[n + k - 2, k], {k, 0, n - 2}]

Evaluating this for n=4 (the maximum number of split hands) yields 5. Or we can list the 5 ordered prefixes explicitly:

(8, 9, 8, 9, 8, 8)
(8, 9, 9, 8, 8, 8)
(9, 8, 8, 9, 8, 8)
(9, 8, 9, 8, 8, 8)
(9, 9, 8, 8, 8, 8)

I am not sure which of these are missing between your results and mine.

 

[iCountNTrack]

Ah, now we're getting somewhere. If I understand correctly, each row in your Excel spreadsheet corresponds to a unique ordered "prefix" of cards in the shoe that yields the indicated 2, 3, or 4-tuple of split hands. Counting this same way, I get 212 distinct "pre-dealer" playouts, not 196.

We agree on all of the 4 two-hand splits and the 16 three-hand splits. But I get more possibilities for four hands. For a specific example, you list 3 instances of the case (9-8, 9-8, 9-8, 9-8), where I see 5 of these. We can count these in two different ways:

First, we can predict how many we should see as described here (http://sites.google.com/site/erfarmer/downloads/blackjack_split.pdf) with the following formula:

Sum[(1 - k / (n - 1)) * Binomial[n + k - 2, k], {k, 0, n - 2}]

Evaluating this for n=4 (the maximum number of split hands) yields 5. Or we can list the 5 ordered prefixes explicitly:

(8, 9, 8, 9, 8, 8)
(8, 9, 9, 8, 8, 8)
(9, 8, 8, 9, 8, 8)
(9, 8, 9, 8, 8, 8)
(9, 9, 8, 8, 8, 8)

I am not sure which of these are missing between your results and mine.

Okay I am glad we are getting somewhere, thanks for the above sequences, I must be missing something, but now it is easier since I have some results to check against. I will take a closer look when I get home. You wish smartphones had an IDE

 

[iCountNTrack]

Finally Fixed

After many hours of pulling hair and a few glasses of whiskey, I was able to figure out what the problem was. There was no bug in the actual code but a stupid algorithmic mistake from my end.

Basically with post split optimal decision you have to calculate the EV of every playing decision taking into account all the cards seen. This will dictate how your cards are dealt. As shown in the following code

double standEV=standFunc(...);
double hitEV=hitFunc(...);
double doubleEV=doubleFunc(...);
double splitEV=splitFunc(...);
if(splitEV>standEV&&splitEV>hitEV&&splitEV>doubleEV)
{
...

problem was that for splitFunc was not only taking into account the seen cards on other split hands but also their totals which is obviously incorrect

so back to our 9-9 vs 8

If you have a 9-8 on first split hand, 9-8 on second split hand, you are playing the third split hand 9-9. Your ev calculation for resplitting that third split hand should only take into account the fact that the deck has now 2 less 9 and 2 less 8 (from split hand 1 and 2), but not the totals on these hands because these totals were already there and are not a result of resplitting.

Anyway i have uploaded the update with fix.
http://code.google.com/p/blackjack-combinatorial-analyzer/downloads/list?saved=1&ts=1312082237
I really need to learn how to create a GUI, console versions are annoying Please let me know if you find any other problems.

Thanks to Eric and K_C for helping me resolved this issue!

 

[ericfarmer]

Anyway i have uploaded the update with fix.
http://code.google.com/p/blackjack-combinatorial-analyzer/downloads/list?saved=1&ts=1312082237
I really need to learn how to create a GUI, console versions are annoying Please let me know if you find any other problems.

Thanks to Eric and K_C for helping me resolved this issue!

Just another $.02 about GUI and text interfaces: I would recommend thinking hard about this, because I think the right choice depends a lot on what you want to do with it. If you want to produce an end product for a relatively unsophisticated end user, then a GUI is nice.

But if the code is for you, then you are not unsophisticated . Or suppose, for example, that another user wants to use your CA to do some interesting analysis-- something that requires multiple "accesses" to your code (e.g., measuring change in EV vs. number of decks, or in the recent actual example of measuring execution time vs. number of decks, etc.). If your code is wrapped in a GUI, then you have just made life a pain for the person who wants to do such analysis.

Of course, my CA is an example of the worst of these two options: it is "bundled" as a non-graphical, clunky-but-portable console interface, but with a per-hand inspection loop that prevents simple use inside a scripted wrapper. (OTOH, an executable as the end product was never my intention. My main goal was a personal one, to (1) tackle the math problems under the hood, and (2) develop code that was loosely coupled from any particular external interface, so I could do a lot of different things with it. The two distributed executables were really just specific examples of what someone could do with it if they wanted.)

 

[MGP]

I think GUI's are nice. You can have multiple results window open with my program. It also makes understanding the information easier if it's displayed properly.

 

[assume_R]

wxWidgets

Just to chime in, for C++ GUI's I highly recommend wxWidgets. It's native to all platforms (windows, mac, linux) and very easy to work with.

 

[ericfarmer]

I think GUI's are nice. You can have multiple results window open with my program. It also makes understanding the information easier if it's displayed properly.

I think this misses my point. I did not mean to suggest that any particular GUI was not "nice." My point was that providing only a graphical interface eliminates any capacity for, or at the very least convenience of, what I guess I would call "user-scriptable automation." For example, suppose that I want to evaluate the stand/hit/double EVs for 6-2 vs. dealer 5 for a parameter sweep of number of decks (1-8), rule variations (S17/H17), and slug removals. (This is an interesting hand in terms of pre/post-split strategy, CDZ- vs. CDZ, etc.)

With a GUI (not just your GUI, but any GUI), this is a manual operation consisting of re-running the same program dozens or hundreds of times. But with a text-based, redirectable interface, this is a few extra lines of code in (insert scripting language of choice here) that I can kick off and go have a sandwich and a beer while it runs.

I certainly agree that for single-shot analysis, visual display of quantitative information (nod to Tufte) is much more effective with a graphical interface than with a console. So I suppose I am really arguing not so much for everyone to have text interfaces, but to (1) post their code (why doesn't everyone do this?), and (2) loosely couple it so that someone can take that code and wrap multiple different interfaces around it relatively easily if desired. (I know of at least three people who have done precisely that with my code, for example, in at least one case with much more aesthetically pleasing results than my game.)

 

[MGP]

I think this misses my point. I did not mean to suggest that any particular GUI was not "nice." My point was that providing only a graphical interface eliminates any capacity for, or at the very least convenience of, what I guess I would call "user-scriptable automation." For example, suppose that I want to evaluate the stand/hit/double EVs for 6-2 vs. dealer 5 for a parameter sweep of number of decks (1-8), rule variations (S17/H17), and slug removals. (This is an interesting hand in terms of pre/post-split strategy, CDZ- vs. CDZ, etc.)

With a GUI (not just your GUI, but any GUI), this is a manual operation consisting of re-running the same program dozens or hundreds of times. But with a text-based, redirectable interface, this is a few extra lines of code in (insert scripting language of choice here) that I can kick off and go have a sandwich and a beer while it runs.

I certainly agree that for single-shot analysis, visual display of quantitative information (nod to Tufte) is much more effective with a graphical interface than with a console. So I suppose I am really arguing not so much for everyone to have text interfaces, but to (1) post their code (why doesn't everyone do this?), and (2) loosely couple it so that someone can take that code and wrap multiple different interfaces around it relatively easily if desired. (I know of at least three people who have done precisely that with my code, for example, in at least one case with much more aesthetically pleasing results than my game.)

That makes sense now. I didn't post my code because I program in spaghetti language and I wasn't about to open up the can of worms involved in trying to explain it. I also didn't take the time to write out a detailed help file but I assume it's clear enough from the GUI that it doesn't need one. So far at least I haven't had any how-to questions. I did post my split method which explains the only code that's difficult.

 

[k_c]

After many hours of pulling hair and a few glasses of whiskey, I was able to figure out what the problem was. There was no bug in the actual code but a stupid algorithmic mistake from my end.

Basically with post split optimal decision you have to calculate the EV of every playing decision taking into account all the cards seen. This will dictate how your cards are dealt. As shown in the following code

double standEV=standFunc(...);
double hitEV=hitFunc(...);
double doubleEV=doubleFunc(...);
double splitEV=splitFunc(...);
if(splitEV>standEV&&splitEV>hitEV&&splitEV>doubleEV)
{
...

problem was that for splitFunc was not only taking into account the seen cards on other split hands but also their totals which is obviously incorrect

so back to our 9-9 vs 8

If you have a 9-8 on first split hand, 9-8 on second split hand, you are playing the third split hand 9-9. Your ev calculation for resplitting that third split hand should only take into account the fact that the deck has now 2 less 9 and 2 less 8 (from split hand 1 and 2), but not the totals on these hands because these totals were already there and are not a result of resplitting.

Anyway i have uploaded the update with fix.
http://code.google.com/p/blackjack-combinatorial-analyzer/downloads/list?saved=1&ts=1312082237
I really need to learn how to create a GUI, console versions are annoying Please let me know if you find any other problems.

Thanks to Eric and K_C for helping me resolved this issue!

I input a composition of 1,1,1,1,1,1,1,1,1,8 (1-10) into your new version.

I computed 10-10 v 6, 3 splits, which is dealt from the above shoe comp. The computed output was:
EV for standing= 0.719264069264 ± 0.625832931119
EV for doubling= -1.7291042291 ± 0.990233071179
EV for hitting= -0.864552114552 ± 0.49511653559
EV for splitting= 0.865196536847 ± 2.63354406919

My program agrees with the stand/double/hit EVs but differs with the split EV. I get .9274 for 3 splits.
3 splits .9274
2 splits .9217
1 split .8659

As far as I can see the best possible strategy is to split when allowed if another 10 is drawn or otherwise stand, so these EVs should be the same as optimally computed EVs. Maybe Eric can post what he gets. I tried using MGP's realtime analysis but I couldn't duplicate anything. I'm probably doing something wrong. I get the same split EV for a full shoe but when I try to input the above composition the values aren't close even for stand/double/hit.