Evaluation of coding skills

[Fguy64]

Greetings.

I am interested in evaluating my skill in implementing the limited feature set that my engine currently has, or to put it a different way, have i squeezed the most out of it?

I suppose nodes/second is a good measure of code efficiency. In order to make comparison to other engines, there would have to be certaing things in common, such as...

same board representation
same limited set of algorithms e.g. alphaBeta + MVV/LVA capture search.
equivalent evaluation function. e.g. material + piece square tables.
same operating system/programming language/hardware.

See what I am saying? Such a measure would factor out things that are examples of technical understanding of concepts of tree search pruning, as opposed to efficient coding skills.

[hgm]

One could of course argue that choice of an improper data structure, wrecking performance, has a bearing on coding skill. E.g. having to search through a mailbox board all the time for locating particular pieces, because no piece list is used.

[Fguy64]

One could of course argue that choice of an improper data structure, wrecking performance, has a bearing on coding skill. E.g. having to search through a mailbox board all the time for locating particular pieces, because no piece list is used.

hmmm, that raises an interesting point. I use a simple 10x10 board. So far, I never search for a particular piece. I just look at squares in the position array, and decide what action to take based on the kind of piece that is on a square. I do maintain a very simple piece list of sorts, but it does not codify piece type, it is just an array of occupied square indexes for each side, which tells me which source squares to examine for moveGen and evaluate(). The only piece location I track is the king.

If you see room for improvement there, without any significant changes to algorithm or board structure, I'm all ears.

[Bill Rogers]

Why 10x10 when an 8x10 works just fine?
Billl

[Edmund]

Why 10x10 when an 8x10 works just fine?
Billl

I only know (apart from bitboards):
- 16x8, where you check out of board with sq & 0x88
- 10x12, where you have a boarder of 2 squares to guard against illegal knight-jumps and check with something like board[sq] == ILLEGAL_SQ


how does 10x10 or 8x10 check for out of board?

[Fguy64]

I chose 10x10 because I had the impression of more efficient moveGen than 8x8, also 10x10 was intuitively very easy for me to understand.

my piece codes in the position array are

0-5 - black pieces
6 - empty square
7 - border squares (off board)
8-13 white pieces

so a typical block of code in moveGen ( diagonal moves by Bishop & Queen) is as follows...

Code: Select all

// diagonal upper left to lower right (White)
dest = src;
while( posn[ dest += 11 ] == empty ) addMove( pI, dest, ply );
if&#40; posn&#91;dest&#93; < 6 ) addCapture&#40; pI, dest, ply );

Code: Select all

// diagonal upper left to lower right (Black)
dest = src;
while( posn[ dest += 11 ] == empty ) addMove( pI, dest, ply );
if( posn[dest] > 7 ) addCapture( pI, dest, ply );

note that pI is a pieceList index


Bill, I'm not familiar with 8x10 how is it easier?

[Edmund]

I chose 10x10 because I had the impression of more efficient moveGen than 8x8, also 10x10 was intuitively very easy for me to understand.
[...]

How do you detect whether a knight moves out of the board on the top or on the bottom?

[Fguy64]

I chose 10x10 because I had the impression of more efficient moveGen than 8x8, also 10x10 was intuitively very easy for me to understand.
[...]

How do you detect whether a knight moves out of the board on the top or on the bottom?

I use a large 2D static array, with 64 rows, one row for each source square, where the elements of the row are the possible target squares.

[Edmund]

I chose 10x10 because I had the impression of more efficient moveGen than 8x8, also 10x10 was intuitively very easy for me to understand.
[...]

How do you detect whether a knight moves out of the board on the top or on the bottom?

I use a large 2D static array, with 64 rows, one row for each source square, where the elements of the row are the possible target squares.

well, if you want to reduce your memory footprint of movegeneration you could easily replace this version with relative movement as well - just as you do with sliders.

For example have a look at the movegen from the CPW-Engine (it is 0x88 but the method is similar):
http://chessprogramming.wikispaces.com/ ... %280x88%29

regards,
Edmund

[Fguy64]

I chose 10x10 because I had the impression of more efficient moveGen than 8x8, also 10x10 was intuitively very easy for me to understand.
[...]

How do you detect whether a knight moves out of the board on the top or on the bottom?

I use a large 2D static array, with 64 rows, one row for each source square, where the elements of the row are the possible target squares.

well, if you want to reduce your memory footprint of movegeneration you could easily replace this version with relative movement as well - just as you do with sliders.

For example have a look at the movegen from the CPW-Engine (it is 0x88 but the method is similar):
http://chessprogramming.wikispaces.com/ ... %280x88%29

regards,
Edmund

It's not clear to me why memory footprint should be an issue in this case, since the memory is allocated only once when the program is initialized. An array like this shouldn't take more than a few KB, no? Are you saying it would be slower with the static array than calculating knight moves on the fly?