Computer Chess Club Archives


Search

Terms

Messages

Subject: Re: Features: Return vs. Effort (new revised table)

Author: Stuart Cracraft

Date: 08:36:44 07/07/04

Go up one level in this thread


On July 07, 2004 at 08:21:47, Tony Werten wrote:

>On July 07, 2004 at 07:51:09, Tord Romstad wrote:
>
>>On July 07, 2004 at 07:35:01, Tony Werten wrote:
>>
>>>On July 07, 2004 at 05:49:44, Tord Romstad wrote:
>>>
>>>>On July 07, 2004 at 05:43:49, Tony Werten wrote:
>>>>
>>>>>On July 07, 2004 at 05:22:22, Tord Romstad wrote:
>>>>>
>>>>>>On July 07, 2004 at 02:26:30, Tony Werten wrote:
>>>>>>
>>>>>>>>5          3         .6              mate-at-a-glance
>>>>>>>
>>>>>>>From my experience, the effort is higher, since it's a very dangerous piece of
>>>>>>>code. Specially since other wrong scoring seems to get damped by alpha beta, but
>>>>>>>a wrong score by a maag is deadly.
>>>>>>
>>>>>>This depends on how you use it.  When I used static mate detection, I didn't
>>>>>>return a mate score, but just used the information for move ordering.  The
>>>>>>mating
>>>>>>move was searched first.  This works very well, even if the mate detection is
>>>>>>correct only 99% of the time.
>>>>>
>>>>>Yes, but that's not a mate at a glance but a move ordering trick.
>>>>
>>>>Technically speaking you are right, but the effect is exactly the same
>>>>as a "mate at a glance".
>>>>
>>>>>Less effort but also less result.
>>>>
>>>>I agree about less effort, but less result?  The only disadvantage of
>>>>using the static mate threat detection only for move ordering is that
>>>>you have to do an extra makemove/unmakemove before returning a mate
>>>>score.  Not an expense worth mentioning ...
>>>
>>>I understand the difference. A mate at a glance should go further than a mate in
>>>1.
>>
>>Yes, if you want to detect mate in several moves, the difference in efficiency
>>increases a bit.
>>
>>>Mate in 1 is easy, specially if you have attacktables.
>>
>>Attack tables make it easier, but it is still by no means trivial.  One
>>problem is "X-ray defences" through the attacking pieces.  My attack
>>tables don't contain this kind of information.
>>
>>>eg you give a check at the back rank, your opponent can put various pieces
>>>between your checking piece and his king, but they are all undefended and can be
>>>captured, so the maag returns checkmate in 3.
>>
>>No, it is much more complicated than that.
>
>I know :) It has cost me a few points.
>
>An undefended piece that can become defended is only 1 of the problems.
>A very nasty one was a knight on h7 and a king on h8 (pawns on g7 and f7) where
>the undefended knightmove to f8, opens an escape on h7. IF of coarse the knight
>wasn't pinned by another piece than the one giving the check. etc etc
>
>Quite powerfull if it works correct. Very deadly if it doesn't. All in all, a
>nice programming excercise.
>
>
>>Consider the following position:
>>
>>[D]7k/R4rpp/4r3/8/8/1b6/8/7K w - -
>>
>>Unless you have some very sophisticated attack tables, you cannot easily
>>see that white has no forced mate.
>
>It does depend on how precise you want to be and how much time you have to
>spend. The easy way out is not to reward the checkmate if the defending piece is
>defended by a slider and the opened up square is closer (measured in ranks if
>you give a rank check else in files ) to the checking piece square than the
>slider from-square.
>
>Even easier is to jump out if a defender is defended by any slider at all. That
>also solves the problem of revealed checks :)
>
>Tony
>
>>
>>>If this happens in quiescence,
>>>it's not sure your normal search would find it as well, even if you do some
>>>plies of checking moves in qsearch.
>>
>>One of the criterions for when to search checks in the qsearch should of
>>course be the presence of a likely mate threat.
>>
>>Tord

Here's the revised table based on recent discussion:

EFFORT   RETURN    RETURN/EFFORT    Feature
1          10        10              capture ordering
3          4         1.33            null move
4          4         1               null move with verification
4          4         1               search pv first
2          1         .5              fractional extensions
4          6         1.5             static exchange evaluator
4          5         1.25            transposition table
4          5         1.25            transposition table with 2-tier repl.
3          3         1               history heuristic, killers, other ordering
2          1         .5              aspiration
4          5         1.25            book learning
3          3         1               position learning
2          2         1               iterative deepening
3          1         .33             internal iterative deepening
2          2         1               pawn hashing w/ complex pawn evaluation
3          3         1               king+pawn hashing w/ king safety evaluation
3          2         .66             capture extension
1          5         5               check extension
1          1         1               pawn to 6th/7th extension
2          3         1.5             futility in qsearch
3          3         1               futility on frontier
3          3         1               futility on pre-frontier
3          2         .66             razoring
5          3         .6              mate-at-a-glance




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.