Tiny Chess Bot Coding Challenge

[Mike Sherwin]

Count all the moves of regular search for each root move (edit: for both sides).

That only tells about the properties of the root position, but does not contribute to the engine picking up the best move, and that's what an engine is for.

Martin Sedlak used this basic idea for move ordering at the root and reported +20 elo. I used only checkmates on a material only searcher and while it did not play great it did seek to checkmate the opponent. And I'm not saying that it is to be used standalone. I'm saying normalize the contribution from this idea to a gentle influence only. It is valuable information to have. Why not use it?

[Ras]

Martin Sedlak used this basic idea for move ordering at the root

That's not what you suggested in your previous posting.

and reported +20 elo.

I don't think that this will score any better than the standard "one move plus QS" for the initial root move ordering. The main purpose of that is IMO to move likely bad moves towards the end of the list so that LMR will work better.

I used only checkmates on a material only searcher and while it did not play great it did seek to checkmate the opponent.

Unless the main search is buggy, mate-in-1 should be obvious in the main search anyway.

Or is the point that due to token limitation, there is no usual main search intended?

[Mike Sherwin]

Martin Sedlak used this basic idea for move ordering at the root

That's not what you suggested in your previous posting.

and reported +20 elo.

I don't think that this will score any better than the standard "one move plus QS" for the initial root move ordering. The main purpose of that is IMO to move likely bad moves towards the end of the list so that LMR will work better.

I used only checkmates on a material only searcher and while it did not play great it did seek to checkmate the opponent.

Unless the main search is buggy, mate-in-1 should be obvious in the main search anyway.

Or is the point that due to token limitation, there is no usual main search intended?

Let's imagine that two root moves are very close in their normal eval. But one of the moves score far more checkmates than the other--that is an indication that there are more ways for the other side to go wrong. It would be similar for null move threats. The engine has to choose between two moves. The one move scores 4 centipawns more but has a much larger number of null move failures indicating that it has to navigate a minefield of threats. Or maybe a move causes the opponent a larger number of null move failures and thus gives the opponent more chances to go wrong. In search it is not only about where it ends up but also the path that is taken to get there when null move and LMR fails. What I described is just the beginning of statistical analysis of root moves. Just a first experiment that I believe is worth investigating.

[Ras]

Let's imagine that two root moves are very close in their normal eval. But one of the moves score far more checkmates than the other--that is an indication that there are more ways for the other side to go wrong.

A one-move deep "threat" is a non-issue for an engine opponent. All it indicates is that the first move necessitates a forced answer, not that it is good in any way. That kind of logic would usually appear in the search itself as "singular extension".

[Mike Sherwin]

Let's imagine that two root moves are very close in their normal eval. But one of the moves score far more checkmates than the other--that is an indication that there are more ways for the other side to go wrong.

A one-move deep "threat" is a non-issue for an engine opponent. All it indicates is that the first move necessitates a forced answer, not that it is good in any way. That kind of logic would usually appear in the search itself as "singular extension".

You are not understanding what I am trying to say. And I don't know how to describe it any clearer. But I'll try. It says nothing about whether a root move is a threat or not a threat. All it does is count checkmates and null move failures in the entire subtree for both sides for each root move. It is just an indication of danger for one side or the other inherent in making that move.

In a simple bot that is a material only searcher it can choose between two equal root moves and play quite intelligently. I'm just proposing an experiment. What's wrong with that?

[hgm]

MicroMax has no PST.

Will you be submitting an entry?

In C#? I don't think so.

[mvanthoor]

Your Rustic blog has been linked quite a few times in the community Discord of the challenge

Cool, but why? There's not too much information in there yet. It's not even complete and the engine's development is down to a snail's pace because of life getting in the way (like, moving, decorating/changing the new house, etc). Maybe, before starting to code on the engine again, I should try to write some stuff for the Rustic website, because I can do that piece-meal, like page-by-page.

Also, I don't really see how a chess engine written from scratch in Rust could contribute to writing this challenge's engine in C# with a limited amount of tokens...

[eduherminio]

Your Rustic blog has been linked quite a few times in the community Discord of the challenge

Cool, but why? There's not too much information in there yet. It's not even complete and the engine's development is down to a snail's pace because of life getting in the way

Because CPW is apparently an elephants' graveyard and your blog is more.. contemporaneous?
SPRT and Move Ordering sections were the linked ones, which I also found very useful myself!

[flok]

MicroMax has no PST.

Will you be submitting an entry?

In C#? I don't think so.

C# is available for Linux!

[mvanthoor]

Because CPW is apparently an elephants' graveyard and your blog is more.. contemporaneous?
SPRT and Move Ordering sections were the linked ones, which I also found very useful myself!

Thanks

CPW is indeed old in many regards, but it is still a good starting point.

Before spending time on (finally) finishing the next Rustic version, it seems it is more important to get the big parts of the chess engine documented, especially magic bitboards. That was a BEAR to get my head around, because many articles explain what they should do, but on the technical details they often deteriorate into incoherent and inconsistent gibberish. Fortunately I documented the workings extensively in the source code itself, so it should be fairly doable to write some pages about this. (There is only one little part I don't understand, but that's a mathematical way to very quickly generate bitboards without a loop. I reference a CPW article about this function. I could have done it with a loop obviously, but then the startup of the engine would have been much slower.)

SPRT is also something that is explained inconceivably bad throughout the internet. The stuff on my website was determined by experimentation: basically try something and see if the result is as expected until I found out how it actually works.

I intend, at some point, to have a website that I can make into a PDF and/or a book even, which can be referenced to write a chess engine in ANY programming language.

I'm quite sure that, if I would start a new engine in a different programming language, I'm going to need it myself; or the code and comments of Rustic itself. I probably couldn't do it on top of my head anymore at this point.