That makes some more sense indeed. I assume you just keep "20" and "400" as counts for depth 1 and 2 separately, and then add the counts coming from that queue. I'll try it at some time.Ronald wrote: ↑Wed Sep 23, 2020 7:29 pmYou don't store the moves in a queue but the resulting positions after you made the moves. So what you sort of doing is a perft2 where you use the leaf positions as the queue for you threads. From the start position you end up with 400 leaf positions from where you do a perft depth - 2.But how do I do this at depth 2?
- First generate moves at depth 1 and store them in a queue with d=1, giving 20 moves...
- Then generate all moves at depth 2 and store them in the same queue with d=2... giving 400 moves and the original 20.
I'm sure that, given a half decent evaluation function (I'm starting out with only material counting and PSQT's from this thread: http://www.talkchess.com/forum3/viewtop ... =7&t=50840) and I'll see where it'll end up. Maybe, because Alpha/Beta depends so heavily on it, I'll add a simple move-ordering in the first version. It's able to search up to 5-6 ply already in a few seconds (in perft, single-threaded), so if alpha/beta and move ordering is added and it can search deeper than that, I'm sure this engine will be able to beat me.Great! A very special moment was when I finally got rofChade to work on my DGT pi with DGT board and got beaten very bad by my own engine. I hope you will get to enjoy that moment soon
I have a DGT Board (two actually), and two Pi 4's.
It is actually the intention to add a level functionality, so I can actually play against it myself.
If the formula Human_Elo = CCRL * 0.7 +840 (which floats around this board) still holds, that functionality would be needed as soon as the engine hits CCRL 1650... which might actually be one of the early versions