1. What do you think, would it be good to give (queen) promotions a bonus sort score? I am not sure. 2. Can history values overflow? Is there a scaling?
re: 1. What do you think, would it be good to give (queen) promotions a bonus sort score? I am not sure. - reasonable idea. needs testing re: 2. Can history values overflow? Is there a scaling? - no. history_moves[piece][target_square] it just get's overwritten every time. We can't overflow piece codes or square indices. In the next video I've added a condition to score killer & history moves only if move is not a capture for otherwise it doesn't make sense for we're scoring captures basing on mvv lva and ignore killer_moves values. On the other hand writing killer and history moves only for quiet moves avoids writing garbage during captures so eventually it saves even more nodes. Btw VICE stores killers and history moves only on quiet moves. Also I use the same arrays like those used in VICE. Real improvements would come when nullmove and LMR would be added (already implemented) - then engine would got 9-10 plies in 5+0 blitz and this is without transposition table. In the very first (which hopefully would be slightly stronger than VICE) initial version I want to draft all the used search techniques (PVS, aspiration search, LMR, NullMove) and then within the later versions we'll go deeper into each one in particular. The more I work on this project the more I want to keep it going. Earlier I had a problem - dropped engine at some level due to lack of ideas of how to proceed. Now I see LOTS of highways to improve it so hopefully it's strength would be growing with my understanding but first I'll add timing and GUI interrupts so it would be able to play tournaments. Also I want to improve evaluation for the first release. Also I would probably take zobrist hashing and based on it 3fold repetition draw detection from TSCP (with some minor changes)
Hello, i hope you are doing fine. I am not sure about your history heuristic implementation, in wiki www.chessprogramming.org/History_Heuristic it presents the technique differently from what i understand from your implementation but your imlementation looks a bit like relative history heuristic www.chessprogramming.org/Relative_History_Heuristic, again i am not sure because i do not understant what it is exactly. Maybe you can explain it to me here oh you can send me a link to a good explanation ?
I use implementation from VICE by Richard Albert aka Bluefever Software. The idea is to order calm moves the following way: 1. Those produced beta cutoff (1st and 2nd killer moves) 2. History moves (those increased alpha) So those moves that has raised the value of alpha are potentially better compared to all the rest, hence ordered first. On practice it doesn't give that big improvement. The must have one is MVV/LVA. Actually the first cpw article describes my implementation in essence, it's just written slightly different. History heuristic has been added for didactic purposes. You can safely drop it because it doesn't give much nowadays as mentioned in CPW.
This is a good example position of how efficient killer move is : 6k1/3q1pp1/pp5p/1r5n/8/1P3PP1/PQ4BP/2R3K1 w - - 0 1
thanks for sharing
1. What do you think, would it be good to give (queen) promotions a bonus sort score? I am not sure.
2. Can history values overflow? Is there a scaling?
re: 1. What do you think, would it be good to give (queen) promotions a bonus sort score? I am not sure.
- reasonable idea. needs testing
re: 2. Can history values overflow? Is there a scaling?
- no.
history_moves[piece][target_square]
it just get's overwritten every time.
We can't overflow piece codes or square indices.
In the next video I've added a condition to score killer & history moves only if move is not a capture for otherwise it doesn't make sense for we're scoring captures basing on mvv lva and ignore killer_moves values. On the other hand writing killer and history moves only for quiet moves avoids writing garbage during captures so eventually it saves even more nodes.
Btw VICE stores killers and history moves only on quiet moves. Also I use the same arrays like those used in VICE.
Real improvements would come when nullmove and LMR would be added (already implemented) - then engine would got 9-10 plies in 5+0 blitz and this is without transposition table.
In the very first (which hopefully would be slightly stronger than VICE) initial version I want to draft all the used search techniques (PVS, aspiration search, LMR, NullMove) and then within the later versions we'll go deeper into each one in particular.
The more I work on this project the more I want to keep it going. Earlier I had a problem - dropped engine at some level due to lack of ideas of how to proceed. Now I see LOTS of highways to improve it so hopefully it's strength would be growing with my understanding but first I'll add timing and GUI interrupts so it would be able to play tournaments. Also I want to improve evaluation for the first release. Also I would probably take zobrist hashing and based on it 3fold repetition draw detection from TSCP (with some minor changes)
how do u evaluate a position and know if the material count is real or just the opponent will capture one of our pieces on the next move?
Quiescence search is used to get rid of the horizon effect you've just mentioned
Assuming a max ply of 64 for the killer moves array, can easily lead to overflows. Stockfish is using 246.
ply is a half-depth value, he has limited his half-depth to 64 everywhere, including quiescence search function
Hello, i hope you are doing fine. I am not sure about your history heuristic implementation, in wiki www.chessprogramming.org/History_Heuristic it presents the technique differently from what i understand from your implementation but your imlementation looks a bit like relative history heuristic www.chessprogramming.org/Relative_History_Heuristic, again i am not sure because i do not understant what it is exactly. Maybe you can explain it to me here oh you can send me a link to a good explanation ?
I use implementation from VICE by Richard Albert aka Bluefever Software. The idea is to order calm moves the following way:
1. Those produced beta cutoff (1st and 2nd killer moves)
2. History moves (those increased alpha)
So those moves that has raised the value of alpha are potentially better compared to all the rest, hence ordered first. On practice it doesn't give that big improvement. The must have one is MVV/LVA.
Actually the first cpw article describes my implementation in essence, it's just written slightly different.
History heuristic has been added for didactic purposes. You can safely drop it because it doesn't give much nowadays as mentioned in CPW.