Page 1 of 1

Hanging Pieces Evaluation

PostPosted: 26 Jul 2006, 10:30
by Edsel Apostol
Hi everyone,

I am implementing an evaluation for hanging pieces but it is disabled for my released versions since I think that it makes my program weaker. It performs well on some positions but the decline in NPS is so big that any increase in knowledge is countered by the low NPS. I think that this can be improved. I might have set some inferior weights on it. Here is the source code. Am I doing this right? Or is there something better? Or hanging pieces is just a waste of time? I observed it searches less nodes at a fixed ply compared to the version not implementing it.

Code: Select all
u64 h, d; int f, c, x, y;
/* penalty for hanging pieces and bonus if it is adequately defended */
    h = (pieces[WHITE][ALL]&~pieces[WHITE][KING]&~pieces[WHITE][PAWN])
    |(pieces[BLACK][ALL]&~pieces[BLACK][KING]&~pieces[BLACK][PAWN]);
    while(h){
        f = fastlsb(h);
        d = bitmask000[f];
        h ^= d;
        c = getcolor(d);
        x = NEWMOVE(f,f,getpiece(d,c),0,0);
        y = swap(x,c);
        opn[c] += y/10;
        end[c] += y/10;
    }


The "swap" function is a Static Exchange Evaluator. It returns the material value of gain or loss on its evaluation. For example it would return a -325 if the knight is hanging, and 325 if it is adequately defended. The "open" and "end" array is being scaled by material at the end of eval. NEWMOVE is a macro for creating a new move with this parameters: NEWMOVE(from,to,piece,captured,promoted).

Edsel

Re: Hanging Pieces Evaluation

PostPosted: 27 Jul 2006, 05:29
by Daniel Shawul
Hi Edsel

Two things:
I guess that you are using the same SEE that you use for move ordering. This is going to make your eval very slow. Have you tried to use attack tables instead, like Ed's approach. That is what i did when i tried to evaluate hanging pieces.
How much is the penalty for a hunging piece? I see that you give the actual value of the piece. I think that is too big. What if one side has too many hunging pieces, the penalty will be the sum of all those, however only one piece is going to be lost.
When the side to move threatens a piece of the opponent, I think that it is better to continue the qsearch as this will resolve the situation. The most important is when null move in qsearch fails high without considering our threatened pieces and we stop search there. To avoid this hunging pieces need to be evaluated.
I just give a penalty of maximum 20 centipawns for each hunging piece. This is considering the fact that my SEE is inaccurate.
So it means that my engine prefers doubled pawns over hunging pieces , which may/may not work.
regards,
Daniel

Re: Hanging Pieces Evaluation

PostPosted: 28 Jul 2006, 08:14
by Edsel Apostol
Hi Daniel,

I think I will just have to scrap this hanging pieces penalty for good. It is a very expensive feature to add in my evaluation function that is already consuming 45% of my program's execution time. I will just have to rely everything to the searh function. Toga/Fruit and Glaurung doesn't support it and they are already strong so I think I will have to go this way too.

Anyway, Scorpio now is becoming stronger. Good luck with your development. I hope I could ask help from you someday if I would need to generate my own bitbases for my program.

Regards,
Edsel