Engine sacrificing pieces!

[hgm]

Beware that FirstChess does not implement any form of Quiescence Search, so that the move choice converges very slowly (if at all) with depth.

[NaltaP312]

for xside you can choose this line
# define Flip(x) ((x)^1) and not used
xside = (WHITE + BLACK) - current_side;

at same time, only one array is available : you can have a function than return the piece color
#define getColor(pc) (pc >> 3)
with the following color
#define COLOR_WHITE 0
#define COLOR_BLACK 1
#define PIECE_NONE 0
#define WHITE_PAWN 1
#define WHITE_KNIGHT 2
#define WHITE_KING 3
#define WHITE_BISHOP 5
#define WHITE_ROOK 6
#define WHITE_QUEEN 7
#define BLACK_PAWN 9
#define BLACK_KNIGHT 10
#define BLACK_KING 11
#define BLACK_BISHOP 13
#define BLACK_ROOK 14
#define BLACK_QUEEN 15

[Anton]

Beware that FirstChess does not implement any form of Quiescence Search, so that the move choice converges very slowly (if at all) with depth.

At the moment I am focused on implementing castling, ep, 50 move rule,
and repetitions, followed by move ordering and mvv / lva. I have read
several times Bruce Morelands description of Quiescence and while I
understand the theory, I have yet to grasp how the code works in practice
in combination with alpha / beta due to my lack of programming skills.
At present, my move generator generates all the moves including captures,
so will I need some modifications to accomodate qsearch?

What is meant by move choice converging?

[Anton]

for xside you can choose this line
# define Flip(x) ((x)^1) and not used
xside = (WHITE + BLACK) - current_side;

at same time, only one array is available : you can have a function than return the piece color
#define getColor(pc) (pc >> 3)
with the following color
#define COLOR_WHITE 0
#define COLOR_BLACK 1
#define PIECE_NONE 0
#define WHITE_PAWN 1
#define WHITE_KNIGHT 2
#define WHITE_KING 3
#define WHITE_BISHOP 5
#define WHITE_ROOK 6
#define WHITE_QUEEN 7
#define BLACK_PAWN 9
#define BLACK_KNIGHT 10
#define BLACK_KING 11
#define BLACK_BISHOP 13
#define BLACK_ROOK 14
#define BLACK_QUEEN 15

Hi Yves,

Thanks for this neat way of shifting colours, Is there a big performance
boost from using one array instead of two? The drawback is that I would
have to rewrite a lot of the move-generation and evaluation code (the
move-generation is 900 lines of code, not including the multi-dimensional
arrays used to store the moves for each piece in every position!) The main
bottleneck at the moment is the evaluation, as can be seen below, not sure
why this is as all I am doing is adding the piece_value with the value found
in the pcsq table:-

Code: Select all

	case ROOK:
        	score += ((value_piece[piece[i]]) + w_rook_pcsq[i]);
				

  %   cumulative   self              self     total           
 time   seconds   seconds    calls   s/call   s/call  name    
 49.07     66.34    66.34 42462247     0.00     0.00  evaluate
 24.48     99.44    33.10  3033327     0.00     0.00  generate
 19.24    125.45    26.01 46124812     0.00     0.00  in_check
  1.73    127.79     2.34 46124716     0.00     0.00  take_back
  1.47    129.78     1.99 88469536     0.00     0.00  gen_push
  1.38    131.65     1.87 46124718     0.00     0.00  make_move
  1.21    133.29     1.64        2     0.82    67.59  search

Code: Select all

[Pierre Bokma]

maybe your eval evaluates with white scores always positieve and black negative while your search expects a score for the side to move. This can be easily solved. In search do:

if(side== with) score = eval()
else score=-eval()

[NaltaP312]

so first build your engine like you want
after, step by step you will increase the strength