So I have an idea for a little pet project (disclaimer - my coding skills are almost entirely self-taught), for which the above would be a key part.

So a 'naive' algorithm might look something like:
What I'd welcome any advice on is where I might get some efficiencies, and whether they are actually worth pursuing (i.e.the decreased solution time justifies the more complex algorithm). Some examples might be:
1) Using isomorphisms (if I have the term correct!) to reduce the number of evaluations - e.g. on a monotone flop, then all cards (either hole or turn/river) either match the board or don't, so on a flop with three hearts, all non-heart cards (of equal rank) have the same effect
2) Evaluating each players 5 player hand, and then only looking at turn and river cards that make a material difference
3) Change the nesting order of the three main loops above - e.g. calculate each 5 card board first and then cycle through the hole-card combinations

May be more I'm not thinking of......

Also, and tips for fast/efficient ways (or do's and don'ts) of managing the data would be much appreciated!

Thanks in advance...

My first tip is to use an efficient method to tell which of two 5-card poker hands wins. From that you can use combinations to decide which of two holdem hands wins given a 5-card community board and go from there.

I did a poker hand equity calculator for fun when learning golang. My first version was super basic and naive. The second version used this method to gain efficiency. It's 10x as fast calculating AA vs KK preflop. I used monte carlo exclusively, a better method is to evaluate all permutations of runouts/hands when feasible, and monte carlo if the combinations get too large. If you're evaluating hand ranges I suspect you will rarely be able to do full runouts much so you can just use monte carlo like I did.

There is an even more efficient method, The TwoPlusTwo method, that uses large datasets of lookup tables. It was used by pokerstove: https://www.codingthewheel.com/archi...r-roundup/#2p2

Here are my repos if you want to take a look:
https://github.com/johannm/naive-holdem-eq
https://github.com/johannm/holdemeq

@Wolfram Thanks. I've been thinking along similar lines to yourself, and I think I will use lookup tables to speed the process

I've been toying with some other ideas around more efficient ways to do exact enumeration. I have some concepts, but (amongst other things) the potential efficiency will depend on the relative speed of the brute force (e.g. lookup tables) versus some parsing of the space via if/then (or some other conditionals)

As a very simple example

If I have a board of QcJcTc, Hero has 9c8c, then Villain needs to beat a Queen High straight flush. They can only do that if:
- They hold the Ac or Kc and there is a Kc/Ac in the runout
- They hold AcKc, in which case they win on any runout

So instead of doing brute force on 990 (=45*44/2) runouts for every hand in villains range, we have some upfront processing and combinatorics (or limited use of the lookup tables if more efficient)

That could work, haven't given it enough thought.

I would however caution against optimizing such edge cases this early. Go for the low hanging fruit first. Get an implementation working and measure it. Then start polishing it and measure your improvements. Also, try to decide on your goal here. How fast is fast enough?

E.g. if your sim is running in less than a second, is it worth it spending lots of time figuring out how you can shave off a few milliseconds? And also make your codebase a lot more complicated and less maintainable. These are things to consider.