Author: Anthony Cozzie
Date: 11:25:24 02/05/04
Go up one level in this thread
On February 05, 2004 at 13:31:56, Robert Hyatt wrote:
>On February 05, 2004 at 13:03:59, Anthony Cozzie wrote:
>
>>On February 05, 2004 at 12:47:26, Robert Hyatt wrote:
>>
>>>On February 05, 2004 at 12:38:20, Anthony Cozzie wrote:
>>>
>>>>On February 05, 2004 at 12:22:44, Bob Durrett wrote:
>>>>
>>>>>
>>>>>Bob Hyatt:
>>>>>
>>>>>I was going through the older CCC bulletins to make sure I didn't miss anything
>>>>>important and noticed the thread begun by Russell,
>>>>>http://www.talkchess.com/forums/1/message.html?345569. After checking Russell's
>>>>>reference, I saw something you wrote cited below. This made me really curious
>>>>>about how the alpha/beta algorithm might be impacted by improvements in the
>>>>>position evaluation code. It seems to me, intuitively, that accurate assessment
>>>>>of positional [and other non-material] factors in a position, along with the
>>>>>correct assessment of material factors, would give
>>>>>values which would change the interpretations of failing alpha or beta tests.
>>>>>It seems that this would significantly alter the way searching would proceed.
>>>>>
>>>>>If this is unclear, I can try to be more detailed if you wish. [I never claimed
>>>>>to be a Pulitzer Prize winning author.]
>>>>>
>>>>>Bob D.
>>>>
>>>>Hey, you are starting to realize why it is so hard to write a good chess program
>>>>:)
>>>>
>>>>One of the reasons Crafty gets good search depth is that it keeps a lot of the
>>>>piece eval simple. For example, Rooks in crafty have just 4 patterns: open
>>>>file, 7th rank, behind (friendly|enemy) passed pawn. The advantage here is that
>>>>the eval is very quantized [0 | 20 | 40]. In Zappa, I do a true (and fairly
>>>>complex) mobility calculation. The advantage is that this catches a lot of
>>>>cases that crafty does not, for example a rook lift
>>>
>>>You didn't look far enough. Crafty handles this but at another place in the
>>>evaluation. Also I do more than "open files" There are half-open files. I
>>>also catch the rook lift directly as I look in _front_ of the rook to see if I
>>>hit any of my own pawns. If not, I like it. And if it bears on the opponent's
>>>king, I like it even more.
>>>
>>>I'm not sure where your "only 4 patterns" came from. Unless you just looked at
>>>the comments alone. IE this:
>>>
>>>/*
>>> ************************************************************
>>> * *
>>> * determine if the rook is on an open file. if it is, *
>>> * determine if this rook attacks another friendly rook, *
>>> * making it difficult to drive the rooks off the file. *
>>> * *
>>> ************************************************************
>>> */
>>> trop = 7;
>>> if (!(file_mask[file] & tree->all_pawns)) {
>>> score += ROOK_OPEN_FILE;
>>> trop = FileDistance(square, tree->b_kingsq);
>>> } else {
>>> if (tree->pawn_score.open_files) {
>>> unsigned char rankmvs = AttacksRank(square) >> (56 - (square & 0x38));
>>>
>>> if (!(rankmvs & tree->pawn_score.open_files))
>>> score -= ROOK_OPEN_FILE >> 1;
>>> }
>>> if (!(file_mask[file] & WhitePawns)) {
>>> score += ROOK_HALF_OPEN_FILE;
>>> trop = FileDistance(square, tree->b_kingsq);
>>> } else if (!(plus8dir[square] & WhitePawns)) {
>>> trop = FileDistance(square, tree->b_kingsq);
>>> }
>>> }
>>>
>>>It does a _lot_ more than just open files in that block of code...
>>>
>>>I don't like rook mobility myself. I used to do it and it is not very expensive
>>>(IE I do bishop mobility at present already). I think the concept of open files
>>>and half-open files is just another way to express mobility, as is rook on the
>>>7th. however I don't blindly go for rook on the 7th as some do, it has to have
>>>a reason for being there or it can be pointless.
>>
>>There's no need to be so defensive. I haven't read the Crafty source in a while
>>as I've pretty much found all your secrets already, so I forgot a few things.
>
>wasn't trying to be "defensive". Just "informative". You had made a statement
>that wasn't correct about Crafty, and I was just pointing that out to not leave
>a wrong impression.
>
>
>>Note also that you are handling only the kingsafety for rook lift here. If I
>>have WP@B2, WR@B3, BP@B7, BR@B8, Zappa will give white an advantage and crafty
>>will not.
>
>yes, but if the bp is at b6, there isn't much of an advantage. I prefer to pick
>up the "advantage" by seeing the file half-open-up at some point.
>
>
>>
>>Anyway, the point remains: You are taking rook mobility, breaking out what you
>>feel are 4-5 key cases, and implementing those. Advantage: quantization and
>>speed. Disadvantage: doesn't catch all cases. Its simply a tradeoff for the
>>programmer to make.
>>
>>anthony
>
>I disagree. your approach doesn't catch all cases either. The one I gave
>previously is one example. with pawns at f7 g6 and h7, a rook on the g-file is
>not a serious threat unless you push your own f and h pawns to try to attack
>that g-pawn. But once it goes away we both notice it is good. So we both are
>going to miss some things, and it is just a matter of picking which you like
>best. I didn't choose to not do mobility for rooks because of the cost. I
>didn't like some of the moves it produces. IE unnecessary pawn advances, or not
>liking rooks side-by-side because they interfere with mobility, etc...
>
>
>I don't think you have to count squares to do adequate mobility. With today's
>search depth, if you have a rook on an open file, most likely you can see deep
>enough, once the file gets opened or half-opened on the enemy king, so that you
>can get the rook over there within the normal search horizon.
>
>Other pieces can use mobility better. Bishops are a good example and I do
>mobility for them since it is not an expensive term at all with table lookups
>available. however, I happen to believe that often mobility is a _result_ of
>something good happening, not the "cause".
>
Zappa's mobility is somewhat more complex than just counting squares.
anthony
>>
>>>
>>>>(R@B3 P@B2 BP@B7) or a rook
>>>>on the 8/6th ranks (which can also be powerful). The disadvantage is that the
>>>>eval is much less quantized. [0 | 1 | 2 ... | 40]. This means that move
>>>>ordering is worse, and so I search less deeply with mobility on than with
>>>>mobility off (not to mention the speed loss). I believe the depth I lose is
>>>>worth Zappa playing a somewhat more natural game, but it is a tradeoff that
>>>>everyone has to make for themselves, of course.
>>>>
>>>>anthony
>>>>
>>>>
>>>>>http://groups.google.com/groups?q=%22The+meaning+of+Alpha+and+Beta%22&hl=en&lr=&ie=UTF-8&selm=a6d9ho%24899%241%40juniper.cis.uab.edu&rnum=1
>>>>>
>>>>>Referenced by:
>>>>>
>>>>>http://www.talkchess.com/forums/1/message.html?345569
>>>>>
>>>>>> An alpha cutoff is what happens when you search the second move,
>>>>>>> and you prove that if you play that move, your opponent has a move
>>>>>>> he can play that will produce a score less than your "lower bound"
>>>>>>> you established for the first move. There is no need to search
>>>>>>> further.
>>>>>>>
>>>>>>> For example, after that +1 on the first move, you try the second
>>>>>>> move and after trying the first move the opponent has in reply to
>>>>>>> that move, you discover you _lose_ a pawn. The score is -1.0...
>>>>>>> There is no need to search other opponent moves to produce a
>>>>>>> score even lower than -1.00, because you already know this move
>>>>>>> is at _least_ -1.00 and possibly worse, while the first move is
>>>>>>> +1.00. You stop searching this move and move on to your third
>>>>>>> choice...
This page took 0.01 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.