RedBedHed wrote: ↑Mon Aug 16, 2021 1:10 am
Thanks so much for all of these awesome research leads!
Of course!
RedBedHed wrote: ↑Tue Aug 17, 2021 5:45 am
Some of the people on this forum really are geniuses. Everything that I have read so far has been eye-opening. But I'd like to think that they are here because they enjoy hacking chess and collaborating to make beautiful software. I'm going to keep thinking that way.
I hope you do keep thinking this way. There are certainly those here in bad faith and there are trolls (I'm speaking generally here), but the vast majority of people I've interacted with here have been nothing but kind and helpful, even to a beginner like me with really dumb questions sometimes and so I try to give back a little bit by helping newer people out on the form when and where I can.
Henk wrote: ↑Mon Aug 16, 2021 11:09 am
If you have no time then you could do this. Implement principal variation search and LMR.
Set LMR to 300. Now you can boast you solved chess but only move ordering need to be improved (a bit).
To do this you only need to change a few lines of code.
Looks like some people did not understand that this supposed to be a quasi-joke. By the way above is a good exercise to show that search depth does not mean much. Only takes say two hours to implement and less if you do some copy pasting.
Henk wrote: ↑Mon Aug 16, 2021 11:09 am
If you have no time then you could do this. Implement principal variation search and LMR.
Set LMR to 300. Now you can boast you solved chess but only move ordering need to be improved (a bit).
To do this you only need to change a few lines of code.
Looks like some people did not understand that this supposed to be a quasi-joke. By the way above is a good exercise to show that search depth does not mean much. Only takes say two hours to implement and less if you do some copy pasting.
I'm sure you are just joking... It was obvious to me .. I just believe that your sense of humor is a bit too hard for a new comer to recognize... Sorry if I seemed harsh on you
RedBedHed wrote: ↑Sun Aug 15, 2021 11:34 pmHow should I evaluate in order to nudge the engine into a castle move?
I give +30 centipawns for having castled, and I rank castling pretty high in move ordering.
In my engine in the King's PST table the squares reached after castling are the most valuable. That encourages the engine to put the king there and it chooses to do so during the opening in most games.
I didn't have to do anything manually to get that behavior. It emerged from texel tuning the PSTs automatically! (Because in the games used for training those where castling happened were statistically more likely to be winning)
Minimal Chess (simple, open source, C#) - Youtube & Github Leorik (competitive, in active development, C#) - Github & Lichess
RedBedHed wrote: ↑Sun Aug 15, 2021 11:34 pmHow should I evaluate in order to nudge the engine into a castle move?
I give +30 centipawns for having castled, and I rank castling pretty high in move ordering.
In my engine in the King's PST table the squares reached after castling are the most valuable. That encourages the engine to put the king there and it chooses to do so during the opening in most games.
I didn't have to do anything manually to get that behavior. It emerged from texel tuning the PSTs automatically! (Because in the games used for training those where castling happened were statistically more likely to be winning)
Same here. For Ceibo, it is the PSTs that drive the engine to castle.
i used to a have reward for castling but once implemented Texel tuning on Ceibo I ended up on removing it, as it would always be tuned to a value of zero. I do have a penalty for loss of castling rights which is 47cp though.
And i think that makes sense, as there 's no point in giving a bonus to the side that castled when a few moves later that safer king position and open rook can be lost. But still the bonus will remain nevertheless. However, losing the ability to castle should be penalized to try to prevent meaningless/forced moves that result in the loss of castling rights.
I tried out the piece-square tables yesterday. You are right! The engine castled all on its own! I kept the table values pretty small (a byte each). It's fascinating how these little numbers have such a profound impact on an engine's play.
Rasthmus and Amanj,
Interesting! I think I will try this approach too and see what it does
@everyone,
The move ordering that I have implemented places attack moves before passive moves. What else should I consider? Should I generate discovered checks and place them first? Would this help to prune more of the tree or is it a bad idea?
RedBedHed wrote: ↑Thu Aug 19, 2021 1:46 am
Thomas and Federico,
I tried out the piece-square tables yesterday. You are right! The engine castled all on its own! I kept the table values pretty small (a byte each). It's fascinating how these little numbers have such a profound impact on an engine's play.
Rasthmus and Amanj,
Interesting! I think I will try this approach too and see what it does
@everyone,
The move ordering that I have implemented places attack moves before passive moves. What else should I consider? Should I generate discovered checks and place them first? Would this help to prune more of the tree or is it a bad idea?
I used to move consider checks before other quiet moves, but thanks to hgm, I was proven wrong, and changing that actually helped the engine. Now, my move ordering is very standard:
- Hash move
- Promotions (there are usually very few of them)
- Winning Captures
- Equal Captures
- Killer moves
- Quiet moves, ordered by history
- Bad captures
I'll be adding Counter move next, and place it after killer moves
RedBedHed wrote: ↑Thu Aug 19, 2021 1:46 am
The move ordering that I have implemented places attack moves before passive moves. What else should I consider? Should I generate discovered checks and place them first? Would this help to prune more of the tree or is it a bad idea?
Sorting the captures with MVV-LVA is trivial to implement fast and very effective. A good first step. To identify a bad capture with SEE is much more complicated.
An extra reason why I have Killers is that a beta cutoff here saves me from generating all the quiet moves. This idea of not generating all the moves at once is called staged move generation, but with your super fast move gen it's probably not a high priority.
What Amanj suggests is surely the better move ordering but a bit overkill at your current point in development. To really profit from good move ordering you'd also need late move reductions. In my personal experience these are finnicky to fine-tune and I still haven't used them in any release version. I would suggest you develop your engine step by step (testing each addition throughly in a few thousand engine vs engine matches) focusing equal attention on improving the search, eval and move ordering.
What features do you currently have implemented?
Minimal Chess (simple, open source, C#) - Youtube & Github Leorik (competitive, in active development, C#) - Github & Lichess