Computer Chess Club Archives

Messages

Subject: Re: Static evaluation after sac, how about asymmetry?

Author: Peter McKenzie

Date: 21:17:16 12/03/99

Go up one level in this thread

```On December 03, 1999 at 21:12:23, Robert Hyatt wrote:

>On December 03, 1999 at 18:10:03, Will Singleton wrote:
>
>>On December 03, 1999 at 08:49:19, Andrew Williams wrote:
>>
>>>Over the last few days, I have been fascinated by the discussions on CCC
>>>about positional sacrifices. Some of the discussion has centred on the value
>>>assigned to the attack that is obtained after the sacrifice and I was wondering
>>>how other programs evaluated the position after Hossa's sac:
>>>
>>>r3q1k1/ppp1rp2/2n1b2Q/8/2P5/3B4/PPP2RPP/5RK1 b - - 0 2
>>>
>>>This is after 1. Bxh6 gxh6 2. Qxh6 from the original position posted by
>>>Peter McKenzie. PostModernist's static evaluation of the position is presented
>>>below. Essentially, it thinks that White is winning by 0.71. The ATTACKTOTAL
>>>score is generated by analyzing the squares around the King to see how many of
>>>them are attacked and what sorts of pieces are attacking them. Please note that
>>>not all the factors that contribute to PM's score are included in the output
>>>below.
>>>
>>>Could other programmers post similar information? I believe that even an
>>>overall static evaluation would be interesting.
>>>
>>>Cheers
>>>
>>>Andrew Williams
>>>
>>>
>>>
>>>SCORE ANALYSIS
>>>BLACK to move
>>>
>>>MATERIAL -137 (Positive means WHITE has more material) W:19086 B:19223
>>>Game stage M
>>>Actual moves played: 1 (halfMoves=1)
>>>
>>>Fifty move counter: 0
>>>
>>>r=547      #       #       #    q=1040     #    k=15939    #
>>>
>>>o=103   o=106   o=103      #    r=565   o=94       #       #
>>>
>>>   #       #    n=346      #    b=346      #       #    Q=1022
>>>
>>>   #       #       #       #       #       #       #       #
>>>
>>>   #       #    P=101      #       #       #       #       #
>>>
>>>   #       #       #    B=344      #       #       #       #
>>>
>>>P=103   P=103   P=98       #       #    R=553   P=103   P=115
>>>
>>>   #       #       #       #       #    R=555   K=15993    #
>>>
>>>
>>>HCW=1   HCB=1
>>>cannotCW=1      cannotCB=1
>>>CCRW=0  CCRB=0
>>>
>>>Piece Bonuses White=4   Piece Bonuses Black=-34
>>>
>>>KINGEXPOSURE WHITE=3    KINGEXPOSURE BLACK=16
>>>DANGERSQUARES WHITE=0   DANGERSQUARES BLACK=5
>>>ATTACKINGFORCE WHITE=21 ATTACKINGFORCE BLACK=0
>>>ATTACKTOTAL WHITE=240   ATTACKTOTAL BLACK=0
>>>
>>>
>>>EVALUATION : 71 (positive means WHITE is winning)
>>
>>For Amateur:
>>
>>r3q1k1/ppp1rp2/2n1b2Q/8/2P5/3B4/PPP2RPP/5RK1 b - -
>>
>>Using a static eval, I get different results if it is White or Black doing the
>>evaluating.  I guess this is a result of my asymmetrical king-safety.
>>
>>White says +0.73, Black says +1.29 (+ is good for white).  Does anyone else do
>>this asymetrically?
>>
>>Will
>
>
>I have always been asymmetric except for a few failed attempts scattered along
>the way...   I think it is the right way myself...

I have never been asymmetric, unless you count a small bonus for the side to
move.

I can see certain practical advantages to an asymmetric evaluation, but in the
long term I personally don't think it is a good idea.  I'm interested in my eval
being as accurate as possible.  If my eval thinks my opponent's sacrificial
attack is unsound then I'm happy to allow the attack even if it means getting
mated from time to time.  If I do get mated, then I can learn from it and
improve the eval so it understands that type of position better.

This approach is in contrast to asymmetric evaluation.  Here, if the 'real'
(pre-asymmetry) eval thinks an opponent's sacrificial attack is unsound the
program may still avoid the attack because the 'fudge factor' will be applied to
the eval which may make the attack appear sound.  Sure, this allows you to avoid
getting mated from time to time but at what cost?  I don't like it for 2
reasons:

1) the program will make other concessions to avoid unsound attacks
2) it is harder to improve the accuracy of the evaluation function because the
fudge factor means the eval isn't 'putting itself on the line'.

I view this issue as similar to penalising blocked positions.  I don't like that
because it isn't related to the objective assessment of the position.  I don't
mind if humans win the odd game from blocked positions vs my program, as I will
examine those games and improve the play of the program in that type of
position.  Also I don't want my program choosing a bad open position instead of
a good closed one (this is a bit extreme, but you get my idea).

Just my personal philosophy regarding computer chess...

cheers,
Peter

```