Poker-AI.org

Nop, IR on the turn is indexing two groups of cards with cardinal 2 and 4. We still need to separate hole cards from board

Ok, I understand

When trying to load the library I get an unsatisfied link error, it say dependant libraries are missing

Also does it run under both, Wnidows and Linux? Because I would need it on both systems.

It does only work for windows x64 sorry. For the unsatisfied link error, you have to put the dll in the classpath.

Sacré d'Jeu said he did port the native code to Java (no JNI), and I asked him if he could publish the code but he didn't answer yet.
I'm a bit lazy and busy so I won't do it myself now, but still interested if anyone does

After several month doing nothing about poker, I decided to code Waugh's indexer in Java.
I didn't look at the original code and just did what was written in the paper (omitting errors, understanding misleading notations and wrong examples ), then tried to optimize it.

Tested and working ! (to do a quite fast test, I implemented a full index/unindex test for 2-2 cards groups)

But I'm quite surprised with performance (of indexing because I didn't optimize unindexing).

I tried it for all flop permutations (311 875 200 indexing).

I modified the C test_full to skip the unindexing part and it took 572s => 545 236 indexings/s on a 2,2 Ghz i7

With my code, it took about 51s on a 2,3Ghz i7, so 6M indexings/s.

I'm not surprised of my code's perf but more by the C test of original code.

To compare, I tried indexing with Djhemlig's flop indexer and it gave me 12M indexings/s so my code is apparently twice slower.

So I'm wondering :
- why is the C code so slow ?
- how did Kevin Waugh observe such speed improvements over Hyperborean's implementation ? ("we also observed a 3.5x speed up of our indexing scheme over Hyperborean") I don't know the Hyperborean's implementation, is it that bad (or just old) ? And did he use its code with this bad execution speed to compare ?..

Have you turned all optimisations on in your C compiler?

I also observed a speed improvement over djhelmig code, it mostly came from the fact, that you can index the streets incrementally, so when you index the river, you basically get the flop and turn for free. That makes a substantial difference in the CFRM algorithm, but maybe not in test cases.

Don't know about C compilation options, kind of a noob for that.
For CFRM you say that Waugh's indexer is faster than Djhemlig's one because of incremental indexing ?
I completely forgot about that in my Java implementation of Waugh's indexer, i'll look into it !

For instance not using the -g flag, as this compile in the debug mode. Also enabling the optimisations, for instance with the -O2 flag.

I don't use gcc often, but O2 should be enough to be faster than java. Turning optimisations on really makes a big difference.

Can this code also be used for Omaha, if you only change the cards per street value, or do you think there could be some problems with that?

edit: ok I have read it again, it will be possible