I'm not aware of books of such kind but chess engine developers usually use conventional resources on the topic such as www.chessprogramming.org/ website as well as talkchess.com forum which contains many snippets within the threads corresponding to certain parts of an engine.
And onother thought: May be it is best to have a global constant or define like const int max_search_depth = 64; in the code and then use that in the array definitions. Otherwise people can be confused and believe that is the same as 64 squares. Or use 100 as an example for max. search depth instead of 64. By the way, is there any check of that ply number in the search? Otherwise an overflow can appear.
that's why within definitions in the comments I write: // init PV table [ply][ply] pv_table[64][64] this shows that 64 is number of plies re: By the way, is there any check of that ply number in the search? Otherwise an overflow can appear. not yet. you're right. need to add it. Btw, good news - I've just applied TSCP's PV move sorting! See our thread(I'll write it in a moment...): talkchess.com/forum3/viewtopic.php?f=7&t=75089
Hi Pierluigi, it's a very good question. Ummm... I would say it's the matter of taste, well at least for me, so here's the deal - the original implementation of the triangle pv I've taken from TSCP engine actually did store PV in the quiescence as well as in the alpha-beta search however the PV line length was exceeding the search depth limit (in fixed depth mode) which is a bit weird to my eyes and also the moves fetched from the quiescence were weird sometimes. As far as my "for all time intention" is trying to bring as simle and as didactic implementation as possible I decided to stick to alpha-beta search only hence the PV line is getting fetched only there but obviously you are free to fetch it from quiescence as well, and play around with it). In general collecting PV especially how it's done in BBC (triangle PV vs using hashtable which is available but not used for this purpose for simplicity) is not obvious feature to have - it just comes handy for debugging and analyzing positions with the engines in the GUI, so it's more like a feature for the end user rather than a part of the engine core.
@@chessprogramming591 thanks for your reply. My problem is actually the pv_length which in case the mate happens in the quiescence, is long 1 (while the pv itself is properly filled). That is driving me crazy....
@@giggetto71 exactly - that's one of the reasons I've been bearing in mind) In order to handle that scenario the code should be organized in a bit different way TSCP: github.com/maksimKorzh/chess_programming/blob/master/didactic_engines/tscp181c/tscp181c/search.c
@@chessprogramming591 I think I found the issue (still need some tests but I am pretty sure it's in the right direction). Essentially in the quiescence function I was only looking at the captures. the problem was that I was not considering the check evasions (of course the non capturing ones which I was considering) so when I was entering the quiescence in a check state and the only evasions were NON capturing move, my gen cap function was returning no moves and I think that was messing up everything...need more testing but before I was also getting sometimes crazy (non legal sometimes) moves in the pv and now everyting looks legal at least..
[edit] Actually, this code is working of course. I just was searching negamax for every legal moves (and then searching deeper for the ones with the highest eval). As a result, my pv_table often didn't have the moves from the best move, just the last one searched. I don't get why this code is correct. I see the triangular PV table is a known concept. But isn't is so that every time an alpha condition is raised, a potential PV is saved? But this isn't necessarily the best move? I tried this code but it is not working for me. This code returns the last instance of triggering the alpha condition on that ply level. So instead of overwriting, I saved all those that trigger this if condition. And a lot of them are refutations of each other and are mutually exclusive. The actual PV I get for one position, the first move is correct and is a queen move setting up a forced checkmate. But the second move of my false PV is an attempt to capture the queen had it not moved during move 1. Going to try a PV TTable instead.
I am a little bit confused by "//init PV length, pv_length[ply] = ply;" I expected pv_length[ply] = 0; And then again "//adjust PV length, pv_length[ply] = pv_length[ply + 1]" where I expected pv_length[ply] = 1 + pv_length[ply + 1]; If you are sure your code works, that's fine, keep it. But for me it somehow looks like you are counting the unused places in the diagonal pv table for deeper ply length also, and I am counting that length from the pv start point on the diagonal. And how does the pv_length in your code grow when you are backtracking towards the root?
Hi Harald re: If you are sure your code works, that's fine, keep it. this is how EXACTLY it's done in TSCP - see search.c in TSCP source. re: But for me it somehow looks like you are counting the unused places in the diagonal pv table for deeper ply length also Now this is the EXACT answer to my thread here (very first question): talkchess.com/forum3/viewtopic.php?f=7&t=75089 re: And how does the pv_length in your code grow when you are backtracking towards the root? This is mystery to me as well) I wish someone could explain to me HOW it works in TSCP)
No, it has to be 'ply' because 'ply' tracks how deep in recursion you are. If your search tree goes 4 ply deep, the pv_length is 4. You are just setting it to 0 and then counting up by one each time you call it. But you already know how deep your ply will be. Unless you dynamically change the search depth for different leaves of the tree.
Thank you for this. I'd been using some horribly hacked together code in my C# engine to extract the PV. This is much neater and makes sense.
thank you
Would it be possible to get some books or materials regarding most of the logic in this chess engine? Or articles. i would really appreciate it
I'm not aware of books of such kind but chess engine developers usually use conventional resources on the topic such as www.chessprogramming.org/ website as well as talkchess.com forum which contains many snippets within the threads corresponding to certain parts of an engine.
And onother thought:
May be it is best to have a global constant or define like
const int max_search_depth = 64;
in the code and then use that in the array definitions.
Otherwise people can be confused and believe that is the same as 64 squares.
Or use 100 as an example for max. search depth instead of 64.
By the way, is there any check of that ply number in the search? Otherwise an overflow can appear.
that's why within definitions in the comments I write:
// init PV table [ply][ply]
pv_table[64][64]
this shows that 64 is number of plies
re: By the way, is there any check of that ply number in the search? Otherwise an overflow can appear.
not yet. you're right. need to add it.
Btw, good news - I've just applied TSCP's PV move sorting! See our thread(I'll write it in a moment...):
talkchess.com/forum3/viewtopic.php?f=7&t=75089
Great video as usual. Very useful. Couple of questions. Should we add the pv code in the quiescence too?
Hi Pierluigi, it's a very good question.
Ummm... I would say it's the matter of taste,
well at least for me, so here's the deal -
the original implementation of the triangle pv I've taken from TSCP engine actually did store PV in the quiescence as well as in the alpha-beta search however the PV line length was exceeding the search depth limit (in fixed depth mode) which is a bit weird to my eyes and also the moves fetched from the quiescence were weird sometimes. As far as my "for all time intention" is trying to bring as simle and as didactic implementation as possible I decided to stick to alpha-beta search only hence the PV line is getting fetched only there but obviously you are free to fetch it from quiescence as well, and play around with it). In general collecting PV especially how it's done in BBC (triangle PV vs using hashtable which is available but not used for this purpose for simplicity) is not obvious feature to have - it just comes handy for debugging and analyzing positions with the engines in the GUI, so it's more like a feature for the end user rather than a part of the engine core.
@@chessprogramming591 thanks for your reply. My problem is actually the pv_length which in case the mate happens in the quiescence, is long 1 (while the pv itself is properly filled). That is driving me crazy....
@@giggetto71 exactly - that's one of the reasons I've been bearing in mind)
In order to handle that scenario the code should be organized in a bit different way TSCP: github.com/maksimKorzh/chess_programming/blob/master/didactic_engines/tscp181c/tscp181c/search.c
@@chessprogramming591 I think I found the issue (still need some tests but I am pretty sure it's in the right direction). Essentially in the quiescence function I was only looking at the captures. the problem was that I was not considering the check evasions (of course the non capturing ones which I was considering) so when I was entering the quiescence in a check state and the only evasions were NON capturing move, my gen cap function was returning no moves and I think that was messing up everything...need more testing but before I was also getting sometimes crazy (non legal sometimes) moves in the pv and now everyting looks legal at least..
[edit] Actually, this code is working of course. I just was searching negamax for every legal moves (and then searching deeper for the ones with the highest eval). As a result, my pv_table often didn't have the moves from the best move, just the last one searched.
I don't get why this code is correct. I see the triangular PV table is a known concept. But isn't is so that every time an alpha condition is raised, a potential PV is saved? But this isn't necessarily the best move? I tried this code but it is not working for me. This code returns the last instance of triggering the alpha condition on that ply level. So instead of overwriting, I saved all those that trigger this if condition. And a lot of them are refutations of each other and are mutually exclusive. The actual PV I get for one position, the first move is correct and is a queen move setting up a forced checkmate. But the second move of my false PV is an attempt to capture the queen had it not moved during move 1. Going to try a PV TTable instead.
I am a little bit confused by
"//init PV length, pv_length[ply] = ply;"
I expected pv_length[ply] = 0;
And then again
"//adjust PV length, pv_length[ply] = pv_length[ply + 1]"
where I expected pv_length[ply] = 1 + pv_length[ply + 1];
If you are sure your code works, that's fine, keep it.
But for me it somehow looks like you are counting the unused places
in the diagonal pv table for deeper ply length also,
and I am counting that length from the pv start point on the diagonal.
And how does the pv_length in your code grow when you are backtracking towards the root?
Hi Harald
re: If you are sure your code works, that's fine, keep it.
this is how EXACTLY it's done in TSCP - see search.c in TSCP source.
re: But for me it somehow looks like you are counting the unused places
in the diagonal pv table for deeper ply length also
Now this is the EXACT answer to my thread here (very first question):
talkchess.com/forum3/viewtopic.php?f=7&t=75089
re: And how does the pv_length in your code grow when you are backtracking towards the root?
This is mystery to me as well) I wish someone could explain to me HOW it works in TSCP)
No, it has to be 'ply' because 'ply' tracks how deep in recursion you are. If your search tree goes 4 ply deep, the pv_length is 4. You are just setting it to 0 and then counting up by one each time you call it. But you already know how deep your ply will be. Unless you dynamically change the search depth for different leaves of the tree.