7 card evaluator

[santiweight]

Some things to decide on:

• Is it worth having in poker-base or is this best in a separate poker-eval package?
• Can we reuse someone's code?
• Should we bind to a C++ library? I have no experience with how easy that would be...
• Can we preevaluate all 7 card hands? Two-Plus-Two does this, but such an approach would likely be best in a separate library to avoid large binaries

Some reading material:

• C++ https://github.com/HenryRLee/PokerHandEvaluator
• A break down of OSS hand evaluators: https://www.codingthewheel.com/archives/poker-hand-evaluator-roundup/
• Haskell implementation of HenryRLee's C++ evaluator: https://github.com/ghais/poker

[santiweight]

Tentatively adding this to hackage release but it's fine imo if this doesn't get in.

[tonyday567]

What HandRank looks like should be uncontroversial. See mine here:m https://github.com/tonyday567/poker-fold/blob/main/src/Poker/Types.hs#L997

But it does then suggest some form of handRank :: [Card] -> HandRanks.

I'd vote for my implementation which starts about here https://github.com/tonyday567/poker-fold/blob/main/src/Poker/Types.hs#L1099. Not because it's the fastest (can't even vouch for correctness yet) but because it's the clearest. Properly documented you can see how the logic all fits together and flows. It's a nice showcase of Haskell, imo.

The rest of poker-fold is pretty much my test bed for preevaluation, as you suggest. The storable vector is 256M lol, but it could be compacted with some suit symmetry magic. Takes a few minutes to calc. I would vote this is outside scope.

[santiweight]

That looks like a fantastic addition to me!

I agree with including HandRanks - that appears completely uncontroversial to me also.

I wonder how we're going to converge on this issue of different evaluators. I don't think about this problem too often myself, but I assume there is no one-size-fits-all evaluator. I would guess that the pre-evaluator is the closest thing (perfect memory usage/fast & constant lookup), but would sadly cause incompatible compile times. Is my understanding correct?

I want to understand this so that we can converge on some criteria for what makes the "best" evaluator so that, for example, if someone has a PR for the evaluator, we know why we would or wouldn't accept it. This question is more long-term but i just wanted to point it out, since I am now aware of four evaluators (2 of yours, one from ghais, and one here).

An alternative design would be to have some separate package called poker-eval with maybe a few different evaluators (co-opted from poker-fold). I don't know whether the inconvenience of such a design is worth it though...

[tonyday567]

I use an MMap thing which I barely understand. It maps a raw file to memory - a memory map, so there's no compile penalty and I haven't noticed a runtime delay on start. You just have to include the big vector file or get the user to make it.

I just needed to have something fast enough to generate the vector, so I'm pretty much done, lol. I am very interested in a speed showdown, however, and want to speed test the other ones and steal some ideas.

[santiweight]

@tonyday567 Wow that's pretty awesome. So it looks we do have a universally acceptable evaluator!

Oh so the only issue is that the library binaries will be 256mb larger is that right? I could foresee myself having an issue with that (since I'm using GHCJS downstream and so I don't want that to be sent over the wire!) but I'm sure we could just have a compilation flag if we want to expose only the slow evaluator. That seems like a reasonable solution to me and not a huge maintenance burden.

Also this is long term - I don't have this issue right now.