Open santiweight opened 3 years ago
Tentatively adding this to hackage release but it's fine imo if this doesn't get in.
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.
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...
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.
@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.
Some things to decide on:
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: