Hmm. I should've spot checked more hands. I think I've found the problem and will post a fix when I have it. Sorry about that, guess I should've tested this a bit more!

Okay, that bug should be fixed. Sorry about that. The cause of that was a subtle difference in the way the acpc logs switch the button around compared to the other log files that this code used to use.

I imported logs now generated by this into PT3, and it seems to work okay, although there's some weirdness in PT3 splitting the log into two different table sessions. Not sure what that's about, but I'll take a look later on.

Hmm, still have bugs with some hands it seems like,

Slumbot|Hyperborean-2011-2p-limit-iro
STATE:794:rc/cc/crf:2cTh|3h7h/9hKh6d/4d:-20|20

Here Slumbot should be BB and Hyperborean the SB with 3h7h, while the converted HH has Slumbot in the SB with 3h7h.

The first name in the log is always BB, right?

And a minor bug with the "ET" which should be behind the timestamp and not the date.

Thanks for all the efforts.

Hmm - I'm a little confused. What you've copied there has the names of the players first, followed by the STATE: keyword. But as far as I can tell, each hand history starts with the STATE: keyword. So that line actually reads:

STATE:794:rc/cc/crf:2cTh|3h7h/9hKh6d/4d:-20|20:Hyperborean-2011-2p-limit-iro|Slumbot

Which has Hyperborean with 2cTh and Slumbot with 3h7h. Does that not seem correct to you? The way I interpret that line is Hyperborean is in the BB. S raises, H calls preflop. Then on the flop H checks, S checks. Then the turn H checks, S bets and H folds.

Herald

Edit: I'm gonna head off since it's like 1am here. Me being a little tired probably has a lot to do with that ET bug not being fixed properly -- that and PT3 doesn't seem to care about it as much as HEM does. I'll upload a fix for the ET issue tomorrow along with any other fixes.

so a log starts with the hand number then the actions, followed with cards, and player names are at the end?

EDIT: you're right, that's indeed how a log file should be read.

Sweet. Thanks for verifying for me.

I've uploaded version 0.5 that fixes the ET timestamp bug. Let me know if you spot any other issues with the converter.

Cheers,
Herald

I tried it but i fail

I'm on win7, is that change something?

Here what happen, i'm totally noob on that stuff

http://my.jetscreenshot.com/demo/20110929-zet4-54kb


Thanks

Sorry, I didn't check back on this thread until today. Your link doesn't work anymore, can you tell me what error you get?

Just in case this is it, this script is not compatible with the latest version of python (python 3). You need to use a python 2.x version instead. Hopefully that addresses your issue.

Herald

Don't know if you Alberta guys are still here.
If you had access to the world's best supercomputer which has like more than 200k GB ram i think, you can pretty easily solve the full non-abstracted game right?

I think they've solved as big as 10^12, unabstracted is 10^18, so a million times bigger I think even 200K GB wouldn't be enough....

Anyone understand any of this??

sick...

Mike did say this earlier in the thread: "We 'only' need a computer 100,000 times as large as we have now to solve heads-up limit hold'em (actually, 5,000 would be enough, as some forms of abstraction are safe)" (emphasis mine).

But there is a difference between a single computer where all the RAM is directly accessible and a huge cluster (which all the biggest supercomputers are) where you have to distribute the computation. That is probably not so easy to do.

interesting...

Yep. Instead of counting the number of game states, the more useful measure for CFR is to count the number of information sets (decision points) across the entire game. Most of CFR's memory usage is because it needs to store two double-precision floats (16 bytes total) for every legal action at every information set. Heads-up Limit Texas Hold'em has 3.2*10^14 information sets. If you make a safe abstraction that only merges hands that have a suit rotation (AsAd == AsAh, AsAc, etc), then you can get to a game with 1.5 * 10^13 information sets and 3.9*10^13 action / information set pairs. Our largest abstraction has 1.5*10^10 action/infoset pairs, so we'd need about 2600x more RAM than we have now. So, 665 TB of RAM would be about the right ballpark. It'd take about that much more cpu time than we use now, too, but historically it's always been the memory limits that have been the biggest limitation.

But I think that we're going to make progress on abstraction and the issues that surround it like abstraction pathologies and the overfitting effect that we've been discussing here. If we can, then we should still be able to use abstraction to produce a strategy that is very close to optimal in the real game. If we can make a strategy that's exploitable for less than (say) 1 milliblind per game, then whether abstraction was used or not, in my opinion that's close enough to say that the game is essentially solved. At 1 milliblind per game, you'd have to observe nearly 100 million games of poker between a strategy and its best response to get 95% confidence that the best response is winning.

It's not as easy or efficient as parallelizing over the cores on one single computer like we do now, but spreading the work over several nodes is how we made the strategies we used in the 2007 and 2008 competitions. My MSc thesis explains how we did it.