A complete 2000 lines of code engine

Discussion of anything and everything relating to chess playing software and machines.

Moderators: bob, hgm, Harvey Williamson

Forum rules
This textbox is used to restore diagrams posted with the [d] tag before the upgrade.
Post Reply
User avatar
xr_a_y
Posts: 768
Joined: Sat Nov 25, 2017 1:28 pm
Location: France

A complete 2000 lines of code engine

Post by xr_a_y » Sat Oct 20, 2018 9:30 am

Being a little tired of finding bugs in Weini, I started a week-end project last sunday. The idea was the following : "starting from a blank page, how far can I go in 2 days now I know a little more on chess programming".

An expected side effect was to get a simple engine to experiment with and maybe find some Weini's bug in it.

It is a mailbox negamax (pvs) engine, with classic pruning trick, a double bucket TT and only PST eval.

After 2 days the engine was working in xboard, validated in perft, finds mate in 8 from a collection I often use and was able to always win against me at fast TC (but loses against fairy-max).

Since then I corrected some stuff but the engine is still quite bad, but working :D

Here's the source code : https://github.com/tryingsomestuff/Mini ... r/minic.cc

Some of you probably can easily spot very bad things that makes it so weak.

Maybe, as a 2000 lines c++ code, it may also become an entry point for beginners. I can open the repository for write if some of you want to contribute.

Sven
Posts: 3826
Joined: Thu May 15, 2008 7:57 pm
Location: Berlin, Germany
Full name: Sven Schüle
Contact:

Re: A complete 2000 lines of code engine

Post by Sven » Sat Oct 20, 2018 12:28 pm

The middlegame PST for kings seems to be wrong, it seems to favor moving the king to higher ranks instead of discouraging that.

I do not understand your MvvLvaScores[][] array. First thing is, it has a lot of redundancy by being a 13x13 array while you only need 6x6 (or 7x7). You never have captures of friendly pieces, and White takes Black can be handled with the same data as Black takes White if you use abs(). Next point, MVV/LVA means "most valuable victim/least valuable aggressor" and is usually implemented differently: all moves capturing a piece of type X should be scored higher than all captures of pieces with a lower value than X, and for two captures of the same piece type the move with the lower-valued moving piece should come first. A possible formula would be:

mvvLvaScore(move) = 6 * type_of_captured_piece(move) - type_of_moving_piece(move)

if the piece type is in the range [1 .. 6]. The factor "6" can of course be any number >= 6.

What about the raw speed of this engine? For instance, your move ordering implementation appears to be quite slow since you calculate the ordering scores for each moves within the comparison operator so you calculate it many times for the same move. What about making the ordering score a member of the move and calculating it only once?

There should be a better way (and maybe even one that is more "C++") than always accessing information related to pieces like this throughout the whole code:

Code: Select all

SOME_ARRAY[position.board[square] + PieceShift]
where PieceShift is 6 and board[square] is the piece type in the range { -6 .. +6 }. I could imagine some accessor methods of the position class, for instance:

Code: Select all

unsigned int Position::pieceIndex(Sq s) const { return board[s] + PieceShift; } // returns a number in [0 .. 12]
Piece Position::pieceType(Sq s) const { return std::abs(board[s]); } // returns a number in [0 .. 6]
Color Position::color(Sq s) const { return Colors[pieceIndex(s)]; }
I wonder why you set the hash move as killer move, I can imagine a negative impact on the quality of your move ordering.

I also wonder why you check for "king capture" within the move loop even though you also have an explicit legality check when making a move so that you can never reach a position where the enemy king can be captured. Furthermore, when ignoring that redundancy, the correct score for a position where the king can be captured should be higher than MATE-ply in my opinion since a "mated" position where all pseudo-legal moves lead to capturing the king would already have occurred one ply earlier.

If you would like to know why this engine is so weak I would suggest to disable all pruning code and test that against the original version. Maybe the problem is somewhere within the pruning?
Maybe, as a 2000 lines c++ code, it may also become an entry point for beginners.
Not sure whether a 2-days work is always suitable for that purpose :-) Once you know there are no serious bugs and it has an acceptable strength then go for it, otherwise I suggest first to fix the code before proposing it to beginners.
Sven Schüle (engine author: Jumbo, KnockOut, Surprise)

Sven
Posts: 3826
Joined: Thu May 15, 2008 7:57 pm
Location: Berlin, Germany
Full name: Sven Schüle
Contact:

Re: A complete 2000 lines of code engine

Post by Sven » Sat Oct 20, 2018 12:50 pm

Sven wrote:
Sat Oct 20, 2018 12:28 pm
The middlegame PST for kings seems to be wrong, it seems to favor moving the king to higher ranks instead of discouraging that.
I may be wrong here, I just saw the PST access is reversed by this code in eval()

Code: Select all

const int s = Signs[p.b[k]+PieceShift];
Square kk = k;
if ( s > 0 ) kk = 63-k;
so PST[x][0] is for H8, not for A1 :-)
Sven Schüle (engine author: Jumbo, KnockOut, Surprise)

User avatar
xr_a_y
Posts: 768
Joined: Sat Nov 25, 2017 1:28 pm
Location: France

Re: A complete 2000 lines of code engine

Post by xr_a_y » Sat Oct 20, 2018 1:43 pm

Thanks for the comment. I Will simplify mvvlva table and piece type accessor. move score is already backuped.

tpoppins
Posts: 919
Joined: Tue Nov 24, 2015 8:11 pm
Location: upstate

Re: A complete 2000 lines of code engine

Post by tpoppins » Sat Oct 20, 2018 6:26 pm

A neat little engine to play with indeed. It lost rather quickly to the 1600-Elo rated Monochrome and obtained a big advantage vs. 1060-rated Soberango, only to go unexpectedly for a threefold repetition.



Here are MinGW builds (32- and 64-bit) of today's code:
minic-01-TP.zip

Note that the execs require -xboard on the command line to enable the Winboard/Xboard mode.
Tirsa Poppins
CCRL

tpoppins
Posts: 919
Joined: Tue Nov 24, 2015 8:11 pm
Location: upstate

Re: A complete 2000 lines of code engine

Post by tpoppins » Sat Oct 20, 2018 6:51 pm

Minic can win a KRK endgame. Amazing! I can name at least a dozen engines many hundreds Elo higher that can only draw.

Tirsa Poppins
CCRL

User avatar
xr_a_y
Posts: 768
Joined: Sat Nov 25, 2017 1:28 pm
Location: France

Re: A complete 2000 lines of code engine

Post by xr_a_y » Sat Oct 20, 2018 7:52 pm

Well using rofchade PST it can even win against fairy-max sometimes ... Thanks for testing it.

User avatar
xr_a_y
Posts: 768
Joined: Sat Nov 25, 2017 1:28 pm
Location: France

Re: A complete 2000 lines of code engine

Post by xr_a_y » Sun Oct 21, 2018 8:03 am

TC : 20sec/40moves, 12 moves from book

Score of fairymax vs Minic: 54 - 14 - 32 [0.700]
Elo difference: 147.19 +/- 59.21

100 of 100 games finished.

User avatar
xr_a_y
Posts: 768
Joined: Sat Nov 25, 2017 1:28 pm
Location: France

Re: A complete 2000 lines of code engine

Post by xr_a_y » Sun Oct 21, 2018 8:02 pm

Version 0.4 is available and is less stupid than the previous ones ... :lol:

tpoppins
Posts: 919
Joined: Tue Nov 24, 2015 8:11 pm
Location: upstate

Re: A complete 2000 lines of code engine

Post by tpoppins » Sun Oct 21, 2018 11:25 pm

And here are Windoze bins for it:

minic-04-TP.zip

But it's 2200+ lines now, you cheat. ;)
Tirsa Poppins
CCRL

Post Reply