New Engine: Eques

[algerbrex]

I few weeks ago I made a post about a new chess engine I was developing: viewtopic.php?t=84616

Thanks for the folks who pointed out the name I chose at the time was already taken by a well known chess related library, so I went back to drawing board and settled on the name Eques, Latin for knight. I've taken many years of Latin, and the knight is my favorite piece, so it seemed like a fitting name. And hopefully it's not taken!

In those past few weeks, development has gone very well, and I'm pleased with my progress.

The most interesting challenge so far has been figuring out how to develop the piece-square table values. Currently Eques contains just one set of tables for each piece, so no tapered evaluation.

The strategy I ended up settling on was to initialize the tables with the standard values for each piece (100 cp for pawns, 300 cp for knights, etc.) and add or subtract a number uniformly chosen in the range [-50, 50]. These initial table values allowed the self-play games I generated to be interesting enough to use for tuning. I played about 60k games with this version, and used the games to tune the next set of piece-square tables. I repeated this process for a few iterations and actually ended up getting decently solid values.

I'm not convinced I've squeezed as much Elo as I can out of iterative tuning process, but I'll continue experimenting with the process. And I'm not sure how much effort I want to invest into tuning before I switch to tapered eval, since I can tell part of the reason the tables aren't optimal is because they're playing double duty for the middle/endgame. For example, here's the king PSQT:

Code: Select all

{
	// King PST
        1,   0,   0,   1,   2,   1,  -1,   0,
	2,   6,   6,   4,   1,   7,  12,  -1,
	4,  18,  18,  13,  11,  14,  17,   0,
	1,  16,  17,  17,  20,  11,  16,  -5,
       -4,   2,  12,   7,  10,   6,   1,  -5,
       -4,   5,   4,   2,  -1,  -3,   1, -16,
       -12, -12,  -2, -15, -17, -10,  -1,  -4,
       -23,  -9, -14, -34, -14, -27,  -1, -14,
}

The values definitely look odd in places, but it looks like the values of favoring developing the king preparation of the endgame while also recognizing keeping it's king in the center isn't optimal.

From my preliminary testing it's ~1700 Elo, and given the current feature list (standard negamax + alpha/beta + qsearch, MVV-LVA and PV move ordering, check extensions, and the single set of piece square tables for the middle and endgame), I'm pretty happy with the performance. I did some more testing yesterday and this current version of Eques was convincingly beating Blunder 4.0.0 (120 Elo +/- 25 Elo after ~150 games), and Blunder 4.0.0 is rated 1621 on the CCRL.

Of course these results aren't completely decisive, but I'm satisfied enough with them to be releasing the first version, 1.0.0, in the next few days.

[algerbrex]

Also, while I was developing Blunder, I mentioned how I was eventually going to build a testing framework for engine development, since being able to do efficient testing was becoming a bottleneck. This problem still presented itself while developing Eques, and I was thinking what the best approach to this issue was.

For now I ended up settling on using cloud computing, and purchasing some time on an instance from AWS EC2. It had 16 cores and charged not to bad of a price per hour of use. Was able to pretty quickly play 60k games several times over.

Not a long-term solution but it was convenient and good enough for now.

[AndrewGrant]

Also, while I was developing Blunder, I mentioned how I was eventually going to build a testing framework for engine development, since being able to do efficient testing was becoming a bottleneck. This problem still presented itself while developing Eques, and I was thinking what the best approach to this issue was.

For now I ended up settling on using cloud computing, and purchasing some time on an instance from AWS EC2. It had 16 cores and charged not to bad of a price per hour of use. Was able to pretty quickly play 60k games several times over.

Not a long-term solution but it was convenient and good enough for now.

OpenBench + fire up spot/ephemeral instances on GCP/AWS.

[algerbrex]

Also, while I was developing Blunder, I mentioned how I was eventually going to build a testing framework for engine development, since being able to do efficient testing was becoming a bottleneck. This problem still presented itself while developing Eques, and I was thinking what the best approach to this issue was.

For now I ended up settling on using cloud computing, and purchasing some time on an instance from AWS EC2. It had 16 cores and charged not to bad of a price per hour of use. Was able to pretty quickly play 60k games several times over.

Not a long-term solution but it was convenient and good enough for now.

OpenBench + fire up spot/ephemeral instances on GCP/AWS.

Thanks for the invite Andrew, I'll definitely consider OpenBench as I move forward.

[AndrewGrant]

Also, while I was developing Blunder, I mentioned how I was eventually going to build a testing framework for engine development, since being able to do efficient testing was becoming a bottleneck. This problem still presented itself while developing Eques, and I was thinking what the best approach to this issue was.

For now I ended up settling on using cloud computing, and purchasing some time on an instance from AWS EC2. It had 16 cores and charged not to bad of a price per hour of use. Was able to pretty quickly play 60k games several times over.

Not a long-term solution but it was convenient and good enough for now.

OpenBench + fire up spot/ephemeral instances on GCP/AWS.

Thanks for the invite Andrew, I'll definitely consider OpenBench as I move forward.

Well not so much an invite -- OpenBench is just a tool.
But this GCP/AWS use case worked just fine for Torch for the year or so of active development.

[algerbrex]

Also, while I was developing Blunder, I mentioned how I was eventually going to build a testing framework for engine development, since being able to do efficient testing was becoming a bottleneck. This problem still presented itself while developing Eques, and I was thinking what the best approach to this issue was.

For now I ended up settling on using cloud computing, and purchasing some time on an instance from AWS EC2. It had 16 cores and charged not to bad of a price per hour of use. Was able to pretty quickly play 60k games several times over.

Not a long-term solution but it was convenient and good enough for now.

OpenBench + fire up spot/ephemeral instances on GCP/AWS.

Thanks for the invite Andrew, I'll definitely consider OpenBench as I move forward.

Well not so much an invite -- OpenBench is just a tool.
But this GCP/AWS use case worked just fine for Torch for the year or so of active development.

Yes, I'm aware of what OpenBench is. I meant invite more in a colloquial sense. And, I imagine you have some level of administrative control in who is allowed to register. But maybe that's not right

Anyway, good to know GCP/AWS worked well for you all, that's encouraging.

[Ciekce]

And, I imagine you have some level of administrative control in who is allowed to register.

AGE doesn't mean the primary instance at chess.grantnet.us, he is talking about setting up your own instance

[algerbrex]

Ah, ok. I see. My bad. Thanks, that makes more sense.