DD Basic Strategy Coding

Quote: Donuts

Ah okay that makes sense.

Still curious why all of my other hands are off by a few % though when te dealer can't possibly have a natural.

Quote: beachbumbabs

All your other hands are affected by the % of times they're negated by a natural. I don't think you've fully accounted for that. Your hands as currently programmed have not been filtered by the times they're beaten before a player decision has been made; they all assume the dealer has not yet acted, but the dealer pre-empts the hand in non ENHC BJ with the peek. I don't see where the peek has been programmed (with its attendant losses) as a pre-requisite to even choosing to stand.

Not that I know how to account for this in your stats, but subtracting out that pre-emptive possibility would raise all your stand EV's because they would no longer be measured against that (negative) outcome as well as any non-natural 2nd card. In effect, you're counting that natural twice by your methodology.

I think. I could be wrong.

Quote: Donuts

I thought that too initially but if I'm looking a hand like 14v8 for example, there's no way the dealer could have a natural.

Quote: beachbumbabs

I guess what I'm saying is that there's a qualifier process your method is skipping, that the wizard's didn't. A certain percentage of 14's are going to auto-lose to dealer's BJ. So only those hands that progress past that initial barrier will be considered. That means that, of the total hands you're using to determine your percentage, you haven't subtracted out those which will auto-lose regardless of value. So I think you're using the wrong total hand denominator in your calculations. It should be total possible hands, less hands that will lose to a natural. Perhaps. Again, I could be wrong.

Quote: Donuts

Still curious why all of my other hands are off by a few % though when te dealer can't possibly have a natural.

Quote: Donuts

Yeah it definitely has only two decks.

Figured out the problem: my shuffle wasn't thorough enough so my shoes weren't technically random.
Anyone know a fast/thorough shuffle algorithm?

int[104]  deck;
int d;
int n;
int z;

// Populate deck[] with the numbers 0-51, each appearing twice
for (d = 0; d < 104; d++)
{
    deck[d] = d / 2;
}

// Shuffle
for (d = 103; d >= 1; d--)
{
    n = random.next(d + 1);
    if (n < d)
    {
        z = deck[n];
        deck[n] = deck[d];
        deck[d] = z;
    }
}

Quote: ThatDonGuy

Here's one, in C/Java-style code:

(random.next(n) returns an integer in the range 0 to (n-1))

int[104]  deck;
int d;
int n;
int z;

// Populate deck[] with the numbers 0-51, each appearing twice
for (d = 0; d < 104; d++)
{
    deck[d] = d / 2;
}

// Shuffle
for (d = 103; d >= 1; d--)
{
    n = random.next(d + 1);
    if (n < d)
    {
        z = deck[n];
        deck[n] = deck[d];
        deck[d] = z;
    }
}

Quote: Donuts

That's actually the one I'm using. Its not thorough enough for some reason. I have to iterate the shuffle 3-4 times to get my numbers within .01% of the Wizard's.

Quote: ThatDonGuy

It could be the underlying Random Number Generator that's the problem. How (if at all) do you seed it?

Quote: Donuts

For i = 1 To 2000
c1 = Int(101 * Rnd * Rnd)
c2 = Int(101 * Rnd * Rnd)
temp = shoe(c1)
shoe(c1) = shoe(c2)
shoe(c2) = temp
Next i

Quote: ThatDonGuy

First of all, rnd * rnd does not generate uniform random numbers. Think about it; if "rnd" chose a number from 1 to 10,000, then 10,000 would come up far more times than 1,000,000. (Also, why do you multiply by 101? There are 104 cards in the shoe.)

Second, if this is the method that you have been using all along, then it's nothing like the one I mentioned - and the reason it wouldn't have worked is, even with 2000 shuffles, it's fairly likely that few, if any, of the top cards in the shoe would have been shuffled.

What you want is:

Randomize
For i = 104 to 2 step -1
c = int(Rnd * i + 1)
If c < i Then
temp = shoe(c)
shoe(c) = shoe(i)
shoe(i) = temp
End If
Next i

Quote: Donuts

So I actually started off with the shuffle in your last post, I think its called the fisher-yates shuffle, and I found it produced significantly less accurate results than the one I'm using now.

Maybe I implemented it wrong? I'll try again.

Quote: ThatDonGuy

When you do implement it, post the code you use for the shuffle. I'll see if I can find the problem.

Quote: Donuts

Sub ShuffleArrayInPlace(shoe)

Randomize
For i = 100 to 0 step -1
c = int(Rnd * i + 1)
If c < i Then
temp = shoe(c)
shoe(c) = shoe(i)
shoe(i) = temp
End If
Next i


'Worksheets("Sheet1").Range("F1:F104") = WorksheetFunction.Transpose(shoe)

End Sub

Ah found the error. the +1 keeps the first card in the same position. Trying again without that.

Quote: ThatDonGuy

Aren't arrays in VBA 1-based (i.e. the first term is shoe(1), not shoe(0))?

If it is, then what your code does is:
Switch shoe(100) with shoe(some number from 1 to 100)
Switch shoe(99) with shoe(some number from 1 to 99)
Switch shoe(98) with shoe(some number from 1 to 98)
...
Switch shoe(3) with shoe(1, 2, or 3)
Switch shoe(2) with shoe(1 or 2)
However, shoe(101) never moves.

If the array is zero-based, then your shoe(0) term is never going to change - your third line should be:

c = int (Rnd * (i + 1))

As it is, c is between 1 and i.

Quote: CrystalMath

Try shoe(i+1) in place of shoe(i).

Quote: CrystalMath

Do you call randomize every time you shuffle? If so, any shuffles started during the same second will be the same. You should only call it once.

Quote: Donuts

Randomize
For i = 100 To 0 Step -1
c = Int(Rnd * (i + 1))
If c < i Then
temp = shoe(c)
shoe(c) = shoe(i + 1)
shoe(i) = temp
End If
Next i

For i = 0 to 100
c = Int(Rnd * (i + 1))

temp = shoe(c)
shoe(c) = shoe(i)
shoe(i) = temp

Next i

Quote: Dieter

Why are you only swapping values if c<i?
Shouldn't it be

temp=shoe(c)
shoe(c)=shoe(i) << change
shoe(i)=temp

So that you don't lose a value?

It shouldn't matter if you're iterating 100 to 0 or 0 to 100, right? You could simplify the program with the possibly more readily optimizable

For i = 0 to 100
c = Int(Rnd * (i + 1))

temp = shoe(c)
shoe(c) = shoe(i)
shoe(i) = temp

Next i

Quote: Donuts

Should I only be randomizing once at the beginning of the code?

Quote: CrystalMath

Yes.

Quote: Wikipedia

To shuffle an array a of n elements (indices 0..n-1):
for i from n − 1 downto 1 do
j ← random integer such that 0 ≤ j ≤ i
exchange a{j} and a{i}

Quote: Donuts

Then I start back at the top with a fresh shoe/shuffle and the same hand for X iterations.

Quote: CrystalMath

I just calculated standing on 2 vs 2A, and I get -0.6646142886031181, which matches the Wizard. I just wanted to rule out that there might be an error in the table.

This is the ev given that the dealer did not have a blackjack.

How close do you come when you start with a dealer card which is not an ace or a ten?

Quote: Dieter

How many iterations?

Quote: Donuts

I'm within .1% and .5% for all hands, including 10/A hands.

For that hand specifically (A2V2) I get -0.28.
I think you mean A2 V A - I get -0.666742

Quote: CrystalMath

Correct A2 V A.

Quote: Donuts

Do you think .1%-.5% matters?

The entire purpose of this is generating index plays for any TC/hand combination. I'm not sure a fraction of a % of EV will matter.

Quote: CrystalMath

It probably won't make much difference, but this would keep me up at night.

Quote: Donuts

Are you using java in your sim?

Quote: Donuts

1M

Quote: Dieter

Yeah, that doesn't feel like a big enough sample to bury the noise for simulation. (For comparison, CVCX talks about billions and quadrillions.)

With around 400k iterations per hand, you can loop through all the possible ways of drawing 4 cards (which covers a lot of the situations, but admittedly not all). 1M rounds doesn't get you to 6 card hands vs 6 card hands. Sure, those are outliers, but outliers are what throw off the results by 3 parts in 1000.

Quote: Donuts

I'm only calculating the stand component at the moment so the players hand is always 2 cards which cuts down on the noise considerably I would think. Isn't 1m what the wizard used?

Quote: Dieter

Try turning it up to 10m and see if your results are closer.

I really don't understand why you want to run random simulations instead of iterating through the possible draws, and then weighting the results based on deck composition.