Got it!
When I first installed Anaconda, I was debating whether to put it on the HD or SSD. So had some path problems with an obsolete install folder.

Back to the videos. =)

I kept trying both.
To be clear, when I start following along with the video, I should still import "pydot", and not "pydot2".
Is that right?

Yes, that's right. "import pydot"

Glad your problem is solved.

A question, is following logic correct?

flops
We can have 52*51*50/6=22100 different flops.
And such (if we would adapt EQarray code a bit) we would require 22100 stored EQArray ('x','y','z','__','__') of 56Mb =113Gb instead of 52^3=140 608 / or 7690Gb.

EQ, all-in at flop
And such, if we set up a tree where a random flop is dealt; the code would each time have to consult one of the 22100 stored EQArray stored at HD.
At first sight, we could say that we are required to generate all these 22100 EQArrays if we get a hand at flop that goes all-in at flop.

However, if we eventually went through all possible flops for each [i,j][a,b] aka went through all the possible EQArrays (that do not conflict); we can conclude that the resulting equity of [i,j][a,b]=sum(1/22100 * EQ('x','y','z','__','__'))
Now, if our code is written correctly, we do not sum 22100 EQ's, we actually sum less as some boards are impossible to be dealt.

And such, instead of having to adapt code; generate and store 22100 EQArray stored at HD; generate each flop; combine the equities; we can actually just use EQArray('__','__','__','__','__') for each hand we get all-in at flop.

Now, EV, all-in at flop
Let's assume that the EV is of algebraic form [a + b EQ('x','y','z','__','__')]
and such
EVflop = sum(1/22100 * [a + b EQ('x','y','z','__','__')])
once again, if our code is written correctly, we do not sum 22100 EV's, we actually sum less as some boards are impossible to be dealt.
= a+b[sum(1/22100 * EQ('x','y','z','__','__'))]
OR = a + b EQ('__','__','__','__','__')

Once again we can just use EQArray('__','__','__','__','__') for each hand we get all-in at flop.

turns
after 4 cards; there are 22100 * 49 = 1 082 900 boards possible.
However, we can once again adapt EQArray code, simply because in the above line each board of 4 cards is present 4 times.
To rephrase it : 52*51*50*49/24 = 270 725
And such we require the software to generate 270 725 EQ('x','y','z','a','__')
or 14.46Tb of information.

EQ turns after flop call
If we move to the turn; there are theoretically 49 EQ('x','y','z','a','__') over which we sum the EQ's. However each time 4 EQArrays will not be counted as they conflict with cards present in the starting hands.
However, we once again arrived into:
EQ(turn) = sum(1/49*EQ('x','y','z','a','__'))
which is equal to EQ('x','y','z','__','__') for the specific flop dealt.

And such instead of having to adapt code for turns; generate and store 270 725 EQ('x','y','z','a','__') stored at HD; generate each turn; combine the equities; we can actually just use EQ('x','y','z','__','__') for the specific flop dealt whenever a hand goes all-in at turn after a flop call.

Once again, at this time we can think that we require EQ('x','y','z','__','__') when we go to turn after flop call; however because we will iterate all flops, and after a flop is generated, we will iterate over all turns, we can just use once again EQArray('__','__','__','__','__') whenever a hand goes all-in at turn after a flop call.

EV turn after flop call
EQ river after flop+turn call
EV river after flop+turn call
idem dito

And such we can just use EQArray('__','__','__','__','__') whenever we get a hand all-in; simply because our software will iterate over all possible flops, all possible turns, all possible rivers and combine the results. And instead of letting our software iterate over all these things correctly and combine correctly; this iteration and combination is already done and present into EQArray('__','__','__','__','__')

quick update on this -- I don't see any salient difference between our code . I'll look at it more tonight.

Not sure if its entirely cool to copy/paste this cause it does include a minor part of the code from the video, but I have trouble debugging near the end of the range video. Anyway if you can see a solution based on just this error that would be extremely helpfull, if not can anyone with knowledge pm me and/or post here so I can pm him and we can maybe agree to take a closer look.

The post is fine, but thanks for thinking of it.

Looks like the nHand variable is 0 when it tries to do the division. Could you try the procedure in post #16?

Hey, sorry i missed post 16, will be more diligent next time with my debugging problems!

In either case the issue is solved but i'm not 100% sure why. I altered the inputs for nhand and nfrac to be >0 manually and that solved the problem. Then I turned them back to 0 and it somehow just kept working.

I'm on video 7.

I've defined the _repr_svg_(self): function, yet when I run

bob = Range()
display(bob)

Im still getting this
<__main__.Range instance at 0x05D2D7B0>

My Range Class doesnt give any problems when I run that cell.

Any help would be greatly appreciated, thanks!

Does it not have to be ranks[i] instead of ranks[1] ?
Meaning, did you not typed from time to time a 1 instead of an i ?

Yes this was part of the problem, fortunatly i only made the mistake once

Hey, check out the Technical FAQ section on the vidpack's page (link in op).

Thanks! Here is error. I've stared at the code in the video for a long while, and I cant see what I've missed.

Hmm maybe someone can help.

In video 5 towards the end i keep getting this error.

The error message there says that you're trying to add a number (a float) to a NoneType which is essentially a special error-indicating thing. And it says the error is coming from a line where you're adding nfrac to the result of the getFrac function. Presumably you expect to be adding two numbers together. Please figure out which of the summands is incorrect, and then investigate why. See post #16 for more ideas about tracking down issues and providing useful debugging info.

This is a known issue that will be added to the errata, but I imagine it's something you are able to figure out.

Does your equityarray instance have a Filename attribute? Should it? What is that code trying to do, and how can it do that?

While your were going through the debugging process, in the video, you also made some last minute changes in the code. It occurred to me that, maybe, in some procedure, you corrected the error-generating bug and updated the cell, but after that you changed some code and didn't updated the cell again before running doFP(). If that's the case, of course, you won't be able to reproduce your earlier results without changing the code back.

I'll watch again this part of the video to see if that might be the case.

Yea, actually all the errata and bugs in the videos so far were introduced by last minute "improvements" or transcription errors that I made while recording. It's hard to think and be on video at the same time .

Anyhow, I found the issue here.. I changed the name of one of the arguments to the getEquityVsHand function from "board" to "b", but forgot to make the change everywhere else in the function body. I forget exactly when I made the change... maybe it wasn't on video.



So, having fixed the equity calcs, my results agree with stevepa's and sevendeuceo's... guess you have more work to do minotaurs

Thanks for hunting that down! I was able to reproduce the results from your video, now, through reintroducing that bug and, of course, temporarily renaming the three relevant equity arrays on the disk so as to force the re-calculation of them. It's nice that this is now sorted out.

Hmm I am stuck here.

I dont think it has the Filename attribute, but I am confused about it. Not exactly sure where to put in the attribute. I tryed various things wich dident seem to solve the problem.

Tryed something like this wich dident help ?
I think it is trying to look for a file but it dont know where to find it ?

Also one other thing.

In my Ipython notebook it looks like it is stored on a localhost:8888. There was also another project in my folder from someone named kevin whom I dont know who is ??

In your video there was another path shown when you moved the preflop.ea.npy file to the documents /iPython Notebooks folder. I moved mine to the similar folder on my system so not sure if this has anything to do with the problem. Just odd ?

Well i think i finally figured it out with the getFilename attribute.

I think i had already tryed this solution yesterday but it produced abother error. so i abonded it.

Anyway now went through it again and put in the () after getFilename and all seems ok now :-)

Hi,

Regarding the second example.
Bet and check for 7h7s are ~20.9.
My code outputs the same results as stevepa and sevendeuceo, and 19.7 for this example. That should be right, given the soln will sue the getequityvshand somewhere, and board changes will have non-negligible effects. What do you guys think?

But i already have b instead of board in that function and i got exactly the same results with doFP() when you were doing calculations to minraise shove game. Not for a digit different. But im getting different numbers when we are doing that big tree (T) For 1st tree all the functions must have worked the same way as yours but than from nowhere im getting different results in 2nd tree (also for tree T i was looking over the code like 3 times and picture as well and they were the same)

The bug only affected EquityArray generation, and the preflop equity array was generated and distributed separately, so there should never have been any issues with the preflop only games.

If your preflop games work but the postflop ones don't, one place to check/focus on would be the getMaxEVsAtNewCardsDP (or so) function.

PS I know I've missed a few questions ITT, and I'll get back to them.

Well i did check setMaxExplEVsAtNatureDP and i changed numCards to numHands like in the video. Everything else was like identical (i changed that numHands to numCards previosuly just because i though that maybe u misstyped that but anyways it didnt change any EV's even for 0.0000001)