MinimalChess - how to move forward?

[hgm]

Pruning captures in QS with SEE > 0 because curEval + SEE < alpha - MARGIN seems wrong. At least for tempo-preserving exchanges (with even SEE value). Because these tend to add. E.g. if there is a B x protected R and a P x protected N on the board, both have SEE = 2. So if alpha = curEval + 3(Pawn), neither SEE will get you there. But B x N will get you above alpha, because you will gain both the exchange and the Knight, by playing the captures one after another.

[amanjpro]

Pruning captures in QS with SEE > 0 because curEval + SEE < alpha - MARGIN seems wrong. At least for tempo-preserving exchanges (with even SEE value). Because these tend to add. E.g. if there is a B x protected R and a P x protected N on the board, both have SEE = 2. So if alpha = curEval + 3(Pawn), neither SEE will get you there. But B x N will get you above alpha, because you will gain both the exchange and the Knight, by playing the captures one after another.

Theoretically I agree with you, but if it works, it works

I remember, in QS I was randomly pruning moves, my SEE had a bug, and it was still performing well... Then I fixed the bug, I lost a few elos, I had to re-tune the search to gain some , sometimes your search is super optimized for the bugs, that fixing them won't do you any good

@Thomas, I am still down for running a bonus tournament for Zahak 4.0 (~2500), Loki 3.5, Barbarossa 0.6, CT800 and MMC
I can give 15m+5s as TC, probably a gauntlet, with 10 games per engine against MMC, and will try to follow the games, and give you a feedback

[lithander]

Pruning captures in QS with SEE > 0 because curEval + SEE < alpha - MARGIN seems wrong.

At least for me it also didn't test too well compared to only pruning captures with SEE < 0. (test results are in one of the previous posts) But maybe in other engines the effect of the speed-up is bigger than the damage it causes.

Personally, in MMC I'm currently not using SEE at all, anymore. When I changed the eval to be incremental the speed advantage of SEE in Q Search wasn't big enough anymore to make it worthwhile. It's back to plain old alpha-beta.

@Thomas, I am still down for running a bonus tournament for Zahak 4.0 (~2500), Loki 3.5, Barbarossa 0.6, CT800 and MMC
I can give 15m+5s as TC, probably a gauntlet, with 10 games per engine against MMC, and will try to follow the games, and give you a feedback

Wow, that would be awesome! I'd really appreciate it!!! I'm in the process of preparing a release of version 0.6 so whenever you you find the time MMC would be ready!

I for sure don't want the tournament without Zahak in it, and adapting the rules for Zahak is a hut unfair.

I suppose no one could begrudge you for changing the rules of the *next* tournament you run to make it possible for your own engine to still compete. Maybe there's a format where not all competitors play the same number of games against every other competitor (swiss-system style) so that you can avoid very uneven (and thus boring) match ups while still keeping the overall Elo range wide enough that you don't have to exclude the weak engines that were originally also meant to have a venue in Zatour.

[amanjpro]

Pruning captures in QS with SEE > 0 because curEval + SEE < alpha - MARGIN seems wrong.

At least for me it also didn't test too well compared to only pruning captures with SEE < 0. (test results are in one of the previous posts) But maybe in other engines the effect of the speed-up is bigger than the damage it causes.

Personally, in MMC I'm currently not using SEE at all, anymore. When I changed the eval to be incremental the speed advantage of SEE in Q Search wasn't big enough anymore to make it worthwhile. It's back to plain old alpha-beta.

@Thomas, I am still down for running a bonus tournament for Zahak 4.0 (~2500), Loki 3.5, Barbarossa 0.6, CT800 and MMC
I can give 15m+5s as TC, probably a gauntlet, with 10 games per engine against MMC, and will try to follow the games, and give you a feedback

Wow, that would be awesome! I'd really appreciate it!!! I'm in the process of preparing a release of version 0.6 so whenever you you find the time MMC would be ready!

I for sure don't want the tournament without Zahak in it, and adapting the rules for Zahak is a hut unfair.

I suppose no one could begrudge you for changing the rules of the *next* tournament you run to make it possible for your own engine to still compete. Maybe there's a format where not all competitors play the same number of games against every other competitor (swiss-system style) so that you can avoid very uneven (and thus boring) match ups while still keeping the overall Elo range wide enough that you don't have to exclude the weak engines that were originally also meant to have a venue in Zatour.

As for the gauntlet, it can't happen until the ZuFi is over, currently we have only played 10 out 100 games, the games are very long, as the TC is 2H+30s

[Chan Rasjid]

I now have MinimalChess as a partner together with Blunder, Raven, ..

My engine is fully bitboard (uses magic bitboard). I think MinimalChess nps is about 95% mine, ok. My estimate of your elo may be Raven's -50/100.

But I don't understand what language you write your engine; how do you get a size of your executable bloated to 21.3 MB!

[Chan Rasjid]

I think MinimalChess suffers from a low search depth, just as mine recently. Other engines would reach a depth of 12/15 wheareas yours seems to just manage a 7/8.

I recently posted on /reddit/computer chess and asked why the low search depth of my engine. They pointed out clearly; I was just reducing 1/2 ply in LMR way too low compared to modern engines. It's all explain in chess wiki lmr telling how senpai and SF do lmr.

[lithander]

My engine is fully bitboard (uses magic bitboard). I think MinimalChess nps is about 95% mine, ok. My estimate of your elo may be Raven's -50/100.

MinimalChess was originally not aiming for playing strength or speed. I wanted to leave out all the tricky optimizations that are imo providing additional complications for understanding the core principles of chess programming. So for example I'm just using an 8x8 array of pieces to represent the board instead of bit boards. Hurts the speed but helps with understanding what's going on.

But I don't understand what language you write your engine; how do you get a size of your executable bloated to 21.3 MB!

I use C#. One reason why chess engines implemented in C/C++ can be so small is that they rely on the C++ standard library that is just preinstalled on any OS. In C# you'd traditionally have to install the .Net Runtime on your computer. But I wanted to save my users the inconvenience of picking the right framework and installing it and so I bundle all the dependencies with the executable. The actual code size of my engine in the bundle is 36 KB for the MinimalChess.dll and 13 KB for the engine.

I think MinimalChess suffers from a low search depth, just as mine recently.
I recently posted on /reddit/computer chess and asked why the low search depth of my engine. They pointed out clearly; I was just reducing 1/2 ply in LMR way too low compared to modern engines. It's all explain in chess wiki lmr telling how senpai and SF do lmr.

The last released version of MinimalChess does not use any reductions beyond null move pruning. The current dev version (which is about 200 ELO stronger) uses a LMR reduction of 2 and consequently searches twice as deep. But if you prune heavily like that only a small part of the tree is actually explored at this depth. The number of explored nodes stays roughly the same. Previously the metaphorical tree was short but spreading it's branches wide and densely. Now it's much higher but sparse. The risk that you miss some interesting quiet moves to play actually increases.