Author: Uri Blass
Date: 22:52:16 01/16/03
Go up one level in this thread
On January 16, 2003 at 17:56:03, Scott Gasch wrote:
>On January 16, 2003 at 17:35:31, Uri Blass wrote:
>
>>On January 16, 2003 at 15:56:43, Scott Gasch wrote:
>>
>>>Hi,
>>>
>>>Bruce's recent posts about code efficiency have had the opposite affect he
>>>intended, on me at least. I've been profiling and looking to trim the fat from
>>>my code since reading them. I have made some progress, I'm glad to report.
>>>
>>>As part of these experiments I enabled a material-only eval routine. Running a
>>>raw speed test with this simple eval I noticed my engine still was only about as
>>>fast as "fast" engines on the same machine. Engines like yace/crafty/ruffian
>>>seem to run about as fast on my machine as my poor engine does with only a
>>>material count eval. This indicates to me that I am generating and scoring
>>>moves too slowly.
>>>
>>>So I profiled my engine with the material only eval and found that it is
>>>dominated by the SEE code. This is partially my own fault because I have a
>>>pretty complicated SEE that handles stuff like accurate pawn promotion scores,
>>>pieces that can't participate because they are pinned against the king,
>>>attackers/defenders exposed in the middle of the exchange, etc.
>>>
>>>My question for those of you with fast move generators, especially those using
>>>SEEs to score moves, is how do you do it? Vincent said something to me about
>>>not scoring all the moves generated which doesn't make any sense (at least to
>>>me). I don't run the hash move through the SEE since I am going to try it first
>>>anyway. And I won't bother to send PxQ through the SEE, clearly it's a winning
>>>move. I send all promotions, apparently even captures, and apparently losing
>>>captures though the SEE though to make sure I have a score on every move
>>>generated, though. I do this because when I go to pick the next best move out
>>>of the list I need to know the score of every move generated. Am I missing some
>>>trick here?
>>>
>>>I have a feeling that monsoon is due for a major code revision after CCT5... I
>>>have a bunch of ideas I want to try like: parallel search, incremental attack
>>>tables instead of an SEE, better POSITION data structure, etc... Thanks for any
>>>and all advice.
>>>
>>>Scott
>>
>>1)I suspect that your SEE may be better than the SEE of fast searchers so I
>>doubt if the fact that you can search less nodes is a real problem.
>>
>>2)I think that for people with complex evaluation the speed of the move
>>generator is not very important and my impression based on previous post of you
>>about a position that monsoon evaluated better than the commercial programs is
>>that monsoon has a very complex evaluation.
>>
>>I read that you are a bad player so I wonder how did you succeed to give monsoon
>>a complex evaluation.
>>
>>Uri
>
>Well for one because I have bad chess skills does not mean that I can't what
>positional features are important in a game. I have bought and read several
>chess books looking for ideas for my eval. I highly recommend Pawn Power in
>Chess and How to Reassess Your Chess. Beyond that I used ideas from other
>engines, "rules of thumb" etc... When I find a position where I think monsoon
>played badly or a PV I do not understand I trace it out, dump the eval terms and
>see if I think anythign is wrong, then tune it up. I do not think my eval is
>that great to be honest. I need a better attack table to do everythign I would
>like to do. I am already slow enough, though... I have no time to spend on
>building one. After CCT5 I will play with this idea though.
>
>Scott
I think that you are not so slow and relative to me you are clearly fast in
nodes per second if you can get the nps of fast searchers with only material
evaluation.
I am afraid that I will be unable to come even with a minimal king safety code
for CCT5.
I think that it may be better if I correct other things first in the evaluation
that may help me to evaluate the king safety opponent.
The problems that I have:
1)Today I have a varaible only for the value of all pieces and not for the value
of pieces of the opponent.
I did it because it was an easy solution to a practical problem
(activating the king in the endgame) because usually if the total value of
pieces is small the value of the opponent pieces is also small.
I think that it is better if I change my code for defining if I am in endgame
first because kingsafety is not relevant in an endgame and my code for defining
if I am in endgame is wrong and it also can cause practical problems(I suspect
that movei lost KRQ vs KRBNPP against chezzzz on ICC because the totl value of
pieces are 14+11=25>24 so it did not know that it should activate the king when
the true is that it should activate the king because 11 was the value of pieces
of the opponent.
2)I evaluate every node so I use incremental evaluation to do things faster.
I do not like to get rid of my incremental piece square tables.
Here is the code that describe movei's evaluation(it is not the full evaluation
but part of the full evaluation).
Note that I have also a code for evaluating changes in the evaluation based on
the previous move and maybe it is better if I get rid of it at least for the
king when it may be important to change the piece square table because it is not
easy to have evalchange without bugs for the king.
int evalroot()
{
int i;
int score=0;
for (i=0;i<numpawns[0];i++)
{
score+=pcsq[0][63-pawns[i][0]];
}
for (i=0;i<numpawns[1];i++)
score-=pcsq[0][pawns[i][1]];
for (i=0;i<numknights[0];i++)
score+=pcsq[1][63-knights[i][0]];
for (i=0;i<numknights[1];i++)
score-=pcsq[1][knights[i][1]];
for (i=0;i<numbishops[0];i++)
score+=pcsq[2][63-bishops[i][0]];
for (i=0;i<numbishops[1];i++)
score-=pcsq[2][bishops[i][1]];
for (i=0;i<numrooks[0];i++)
score+=pcsq[3][63-rooks[i][0]];
for (i=0;i<numrooks[1];i++)
score-=pcsq[3][rooks[i][1]];
for (i=0;i<numqueens[0];i++)
score+=pcsq[4][63-queens[i][0]];
for (i=0;i<numqueens[1];i++)
score-=pcsq[4][queens[i][1]];
if (valuepieces>24)
score+=pcsq[5][63-kingsquare[0]]-pcsq[5][kingsquare[1]];
else
score+=kingendgame[63-kingsquare[0]]-kingendgame[kingsquare[1]];
if (side==LIGHT)
return score+evalrootpawns();
else
return 0-score-evalrootpawns();
}
I know that part of it (valuepieces>24) is not good and it is better if I use
the value of the opponent pieces and even this is not 100% ok and it is better
if the score is going to be changed incrementally based on the value of the
opponent pieces and not having only 2 arrays.
Maybe I should use incremental evaluation only for
the score without king's score and evaluate the king score seperately based on
some average between the tables when the weight in the average are defined based
on the material of the opponent.
Advices are appriciated.
Uri
This page took 0 seconds to execute
Last modified: Thu, 15 Apr 21 08:11:13 -0700
Current Computer Chess Club Forums at Talkchess. This site by Sean Mintz.