I would say the first things you need to do to have a reasonable eval is:
- piece on square tables. there are of course many ways to do it, but the Fruit approach is a very good one, since it reduces massively the number of arbitrary parameters (parametric PSQ). In particular Ke2? would not have been played given a reasonable PSQ table.
- Pawn structures of course. Although doubled backward isolated pawns and the like are important, the most important elo-wise is probably passed pawns. Without any passed pawns knowledge your engine is likely to be quite silly in endgames. In this game, white should have initiated a plan to push the h passed pawn much earlier.
- The main improvements will come from the search at this early point of developpement. I've found the Null Move to be a massive elo gain when I started developping DoubleCheck (and just had a basic SEE ordering + PVS algorithm, eval was just PSQ tables)
IMO the opening book should be the job of the GUI. If you use the UCI protocol you should never have to worry about coding the book stuff yourself.
Coding an opening book, both generation and look-up, is easy. These routines have to be present in the program because (in part), the end user may be running CookieCat on a small system (e.g., Raspberry Pi) where there is no GUI available.
And it's a similar story for tablebases. The only difference is that the TB generator is a separate program, although I could integrate it later as it too can run on a small system. How small? It was written and tested on a 1986 Mac Plus with a whopping 4 MB of RAM and a 20 MB drive.
CookieCat has hook stubs for xboard and UCI. But I may delete these and use my own protocol instead with filter programs to handle xboard/UCI.
lucasart wrote:I would say the first things you need to do to have a reasonable eval is:
- piece on square tables. there are of course many ways to do it, but the Fruit approach is a very good one, since it reduces massively the number of arbitrary parameters (parametric PSQ). In particular Ke2? would not have been played given a reasonable PSQ table.
- Pawn structures of course. Although doubled backward isolated pawns and the like are important, the most important elo-wise is probably passed pawns. Without any passed pawns knowledge your engine is likely to be quite silly in endgames. In this game, white should have initiated a plan to push the h passed pawn much earlier.
- The main improvements will come from the search at this early point of developpement. I've found the Null Move to be a massive elo gain when I started developping DoubleCheck (and just had a basic SEE ordering + PVS algorithm, eval was just PSQ tables)
CookieCat already has a POS table for pawn advancement; adding more tables is easy and will be done soon.
The program already knows how to detect passed pawns and soon will be able to identify other pawn features. There is already a pawn structure/score transposition table.
CookieCat also knows about null moves and these are correctly handled by the execute/retract routines. Adding a null move search is easy.
That's 171 lines of code per day since October 3rd when I started BozoChess from scratch.
The evaluator is good enough for now. Getting the tablebase code entirely finished, writing the PGN and EPD parsers, writing the opening book routines, and working on thread issues all have higher priority.
lucasart wrote:Let me know when you have a functional and stable enough program that I can test. Is it going to be UCI compatible ?
I'm doing a GPL Blitz rating list (cf. my post in the Tournament forum), and CookieCat 1.0 would be a nice addition to my collection !
Someday CookieCat will be both xboard and UCI compatible, but this is likely to require a polygot-like separate filter program.
In the meantime, you are welcome to review and test the program and its simple console interface. Just send me a PM with your email address and a copy of the source will be on its way.
lucasart wrote:Let me know when you have a functional and stable enough program that I can test. Is it going to be UCI compatible ?
I'm doing a GPL Blitz rating list (cf. my post in the Tournament forum), and CookieCat 1.0 would be a nice addition to my collection !
Someday CookieCat will be both xboard and UCI compatible, but this is likely to require a polygot-like separate filter program.
In the meantime, you are welcome to review and test the program and its simple console interface. Just send me a PM with your email address and a copy of the source will be on its way.
I'll probably wait for an UCI or Xboard version before. I can't really test without, and as for reviewing code.. I'm a noob in PASCAL, so I couldn't really help you there
Although I have done some PASCAL in the past, and at the time I thought it was the best language ever! That was after my Visual Basic phase, and before I learnt C
lucasart wrote:I'll probably wait for an UCI or Xboard version before. I can't really test without, and as for reviewing code.. I'm a noob in PASCAL, so I couldn't really help you there
There will be a lengthy wait, as xboard/UCI support will very likely be the very last piece added before exiting the beta phase.
Playing strength is not a goal above all other goals. There are already plenty of free, strong programs. But how many of these are truly portable? How many were written with a highly permissive, BSD style license? How many were coded so that a relative neophyte could understand and modify the program?
I've connected the tablebase transposition table probe and the tablebase file probe with the first having priority over the second. An object of the enclosing class, tbwrangler, is queried by the search at ply > 0 whenever the position's wood (count of chessmen) integer component drops into the TB man count range. This includes the quiescence search, but this is just for testing and will be changed.
Here is a five second per move autoplay game using the TB code (the first ten ply manually inserted):
