Author: scott farrell
Date: 09:39:20 01/17/03
Go up one level in this thread
On January 17, 2003 at 01:52:16, Uri Blass wrote:
>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.
>
I know crafty does hashing/caching for KS for the king. I (an dI guess everyone)
does it for pawns, but I can do it for the king, because I have to hash too many
pieces in to make it work.
>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.