Please either Upload the full video in the first place, make the second part start where the first one ends or at least use chapters or a link to skip the first part 🙏 Otherwise great video dude, I've barely seen someone produce such high quality videos, while still being relatively small, so continue on, you earned another sub! 😁
6:12 timestamp for people who just finished your "Neat AI does Cactus Kevs Poker Hand Evaluator Part 1" and want to skip straight to the next section as this covers both
@@neatai6702 sorry, it was a timestamp for people who just finished your "Neat AI does Cactus Kevs Poker Hand Evaluator Part 1" and want to skip straight to the next section as this covers both
with the final implementation, can't you skip step 2? if my understanding is correct, a lookup table based on the multiplication of the primes could contain all the high card/straight options as well. also, if we already established that big arrays are ok, why not just do it in a more straight forward way: just take the 4 bits that represent the value of each card and concatenate those 5 numbers, this gives you 20 bits that represent any combination (without suits). while it means that we'll have many repetitions in the array, since it's not order-independent, the resulting array length is only 1048576, which is way less than the 100 million proposed in the video.
What is the purpose of including the 4 bit rank encoding? Unless I missed something it is never used. The rank flags are used for flushes, and 5 unique cards, and the primes are used for all other cases.
Do you know the hand evaluator which is based on a one big look-up table and which you have to evaluate five times in a row to get the final handrank? I've been wondering how such a lookup table is generated ever since I first heard about it. What optimization is it based on or is it just a pure brute force approach?
Hey Looper. You may be thinking of the eval system first described - and then published - by Ray Wotten; user RayW on the twoplustwo forums. He published the complete "C" source code on a post dated 01-04-2007 (06:06). This is also available on GitHub in C++ as "TwoPlusTwoHandEvaluator". I've been using that basic technique for the last 15+ years in my code; it's amazingly fast - 350 million 7-card evals per second on a 3.06GHz Intel processor, although the speed is constrained by how fast your memory and memory bus is. The idea here is that you pre-build the lookup table, doing all the evals ahead of time. At startup, you load this table into memory. To look up a seven-card hand, you do seven memory pointer lookups. It's even faster if you're doing multiple hole card lookups for the same board; you do the five-card board lookup once, and only need the last two lookups for each hole card combo (this is for Holdem). To adapt this for PLO: set the board cards then do 6 hole card lookups, one for each two-card combos of the pocket cards. The technique is exhaustively explained in a web-archive-org post called "The Great Poker Hand Evaluator", in the section about half-way down called The Two Plus Two Evaluator. The last node of the search is some value you can pre-define that describes the handrank. I might suggest that however you structure this value, that you be able to compare one hand with another to see which is the better hand. So, if eval1 > eval2, eval1 is the better of the two.
Please either Upload the full video in the first place, make the second part start where the first one ends or at least use chapters or a link to skip the first part 🙏
Otherwise great video dude, I've barely seen someone produce such high quality videos, while still being relatively small, so continue on, you earned another sub! 😁
Good idea to cut number of strategies observing to easy managed number! Even simple RL algorithms will work with such methods! Very well done!
Why not mention the later improvement by Paul Senzee?
6:12 timestamp for people who just finished your "Neat AI does Cactus Kevs Poker Hand Evaluator Part 1" and want to skip straight to the next section as this covers both
??
Do you have a flush?
thank you
@@neatai6702 sorry, it was a timestamp for people who just finished your "Neat AI does Cactus Kevs Poker Hand Evaluator Part 1" and want to skip straight to the next section as this covers both
with the final implementation, can't you skip step 2? if my understanding is correct, a lookup table based on the multiplication of the primes could contain all the high card/straight options as well.
also, if we already established that big arrays are ok, why not just do it in a more straight forward way: just take the 4 bits that represent the value of each card and concatenate those 5 numbers, this gives you 20 bits that represent any combination (without suits). while it means that we'll have many repetitions in the array, since it's not order-independent, the resulting array length is only 1048576, which is way less than the 100 million proposed in the video.
I think step two is a lot faster if it does return true, so it saves time in the long run by skipping step 3 for the cases that don't need it.
What is the purpose of including the 4 bit rank encoding? Unless I missed something it is never used. The rank flags are used for flushes, and 5 unique cards, and the primes are used for all other cases.
Do you know the hand evaluator which is based on a one big look-up table and which you have to evaluate five times in a row to get the final handrank? I've been wondering how such a lookup table is generated ever since I first heard about it. What optimization is it based on or is it just a pure brute force approach?
Hey Looper. You may be thinking of the eval system first described - and then published - by Ray Wotten; user RayW on the twoplustwo forums. He published the complete "C" source code on a post dated 01-04-2007 (06:06). This is also available on GitHub in C++ as "TwoPlusTwoHandEvaluator".
I've been using that basic technique for the last 15+ years in my code; it's amazingly fast - 350 million 7-card evals per second on a 3.06GHz Intel processor, although the speed is constrained by how fast your memory and memory bus is.
The idea here is that you pre-build the lookup table, doing all the evals ahead of time. At startup, you load this table into memory. To look up a seven-card hand, you do seven memory pointer lookups. It's even faster if you're doing multiple hole card lookups for the same board; you do the five-card board lookup once, and only need the last two lookups for each hole card combo (this is for Holdem).
To adapt this for PLO: set the board cards then do 6 hole card lookups, one for each two-card combos of the pocket cards.
The technique is exhaustively explained in a web-archive-org post called "The Great Poker Hand Evaluator", in the section about half-way down called The Two Plus Two Evaluator.
The last node of the search is some value you can pre-define that describes the handrank. I might suggest that however you structure this value, that you be able to compare one hand with another to see which is the better hand. So, if eval1 > eval2, eval1 is the better of the two.
This was a great video! I really have to...hand it to you.
😎
Thanks for all your feedback ! more videos coming soon...
@@neatai6702 You’re most welcome, though I’d tend to categorize my comments more as “puns” than “feedback”! 😎
Great video, the only thing that's false is that in the end, I'm interested in seeing you make a poker AI, but I don't know what to do.
Yep. Same lol