Limiting extensions

Programming Topics (Computer Chess) and technical aspects as test techniques, book building, program tuning etc

Moderator: Andres Valverde

Limiting extensions

Postby David Weller » 23 Feb 2005, 15:34

Currently, GES extends without limit for these standard reasons:
check, p27, mate, 1reply, and recap

My plan, is to try 'fractional' extensions again.

Some pseudo code with extension stuff:

Code: Select all
search(alpha, beta, depth, extensions){
    if(is_one_reply_to_check) extensions += 1rep;
    if(is_mate_threat) extensions += mate;
    for each move{
        domove()
        ext_move = extensions
        if(is_check) ext_move += check;
        if(is_p27th) ext_move += p27th;
        if(is_recap) ext_move += recap;

        if(ext_move >= ONEPLY){
             extend = 1;
             ext_move -= ONEPLY;
             if(ext_move >= ONEPLY) ext_move = 3 * ONEPLY / 4;
        }
        val = -search(-beta, -alpha, depth+extend-1, ext_move)
        .....
    }
}


Does this basically make sense, or am I missing something?
[besides syntax errors, misspellings, and non-conventional practices :)]
User avatar
David Weller
 
Posts: 135
Joined: 26 Sep 2004, 20:30
Location: USA

Re: Limiting extensions

Postby Pallav Nawani » 23 Feb 2005, 16:16

Hi,

Seems quite ok to me. If you want you can fold extensions and depth into one variable, this will allow you to avoid passing an extra parameter.

Pallav
User avatar
Pallav Nawani
 
Posts: 147
Joined: 26 Sep 2004, 20:00
Location: Dehradun, India

Re: Limiting extensions

Postby Chan Rasjid » 23 Feb 2005, 16:48

In a recent thread over CCC, some said a (cardinal) principle is never to extend a single move more than a ply (maybe at most by fraction of 1 ply).
I think the rationale is a winning line depends on many moves and there should not be over empahsis on a single move.

By a similar reasoning it may be good to limit a MAX_EXTENTION for any
line of play.

Rasjid
Chan Rasjid
 
Posts: 73
Joined: 23 Feb 2005, 16:36
Location: Singapore

Re: Limiting extensions

Postby Ross Boyd » 23 Feb 2005, 20:18

Hi David,
In a recent thread over CCC, some said a (cardinal) principle is never to extend a single move more than a ply (maybe at most by fraction of 1 ply).


I'd have to agree.

In my experience, it is generally a no-no to extend a node more than a ply. It seems to destabilise the hash table. It makes hash entries of over-extended nodes override their 'peers'. Its sort of like selective blindness. Quiet moves get overlooked.

By the way, only allowing one ply extensions makes the single-reply-to-check extension a little problematic. I detect being in check AND single-reply to check usually at the same node. Rather than double extend this node, I pass the single-reply extension as a parameter to the next node... and extend there. Ideally, I'd rather extend moves that GIVE check and then extend single replies at the next node.

The only exception I have to limiting extensions to one ply is Rebel's 3ply extension for a capture which leads to a pawns v pawns only endgame.... but I'm beginning to consider this a liability too. If the pawn evaluation is inaccurate it makes things even worse.

As far as limiting total extensions, I only limit mate threat extensions as they can really explode the tree.

Ross
User avatar
Ross Boyd
 
Posts: 83
Joined: 26 Sep 2004, 23:07
Location: Wollongong, Australia

Re: Limiting extensions

Postby Sven Schüle » 23 Feb 2005, 23:55

David Weller wrote:Currently, GES extends without limit for these standard reasons:
check, p27, mate, 1reply, and recap
Hi David,
"p27", I never read this before, could you please explain this or post a link where I can read something about it? Google didn't help me :(
Thanks,
Sven
User avatar
Sven Schüle
 
Posts: 240
Joined: 26 Sep 2004, 20:19
Location: Berlin, Germany

Re: Limiting extensions

Postby Uri Blass » 24 Feb 2005, 00:12

Hi Sven, p27 probably means pawn to the 7th rank.
User avatar
Uri Blass
 
Posts: 727
Joined: 09 Oct 2004, 05:59
Location: Tel-Aviv

Re: Limiting extensions

Postby Sven Schüle » 24 Feb 2005, 00:17

Thank you, Uri, that sounds reasonable. The translation of "p27" into "pawn27" enlightens it. When I read "p27", I only saw "P twentyseven" ...

Sven
User avatar
Sven Schüle
 
Posts: 240
Joined: 26 Sep 2004, 20:19
Location: Berlin, Germany

Re: Limiting extensions

Postby David Weller » 24 Feb 2005, 05:28

Forgive my laziness please,
Uri is correct
I have a bad habit of using short cryptic names
User avatar
David Weller
 
Posts: 135
Joined: 26 Sep 2004, 20:30
Location: USA

Re: Limiting extensions

Postby Tony van Roon-Werten » 24 Feb 2005, 10:32

David Weller wrote:Currently, GES extends without limit for these standard reasons:
check, p27, mate, 1reply, and recap

My plan, is to try 'fractional' extensions again.

Some pseudo code with extension stuff:

Code: Select all
search(alpha, beta, depth, extensions){
    if(is_one_reply_to_check) extensions += 1rep;
    if(is_mate_threat) extensions += mate;
    for each move{
        domove()
        ext_move = extensions
        if(is_check) ext_move += check;
        if(is_p27th) ext_move += p27th;
        if(is_recap) ext_move += recap;

        if(ext_move >= ONEPLY){
             extend = 1;
             ext_move -= ONEPLY;
             if(ext_move >= ONEPLY) ext_move = 3 * ONEPLY / 4;
        }
        val = -search(-beta, -alpha, depth+extend-1, ext_move)
        .....
    }
}


Does this basically make sense, or am I missing something?
[besides syntax errors, misspellings, and non-conventional practices :)]


Depending on what you exactly try to achieve:
ext_move -= ONEPLY should most likely be: ext_move = ONEPLY

(Now when you enter with 1.1 extension, it becomes 0.1 )

I would remove the line after it and just adjust the individual extensions amount fe p27=0.75, check=0.75 and check+p27=1.0

Tony
Tony van Roon-Werten
 
Posts: 99
Joined: 02 Oct 2004, 15:31
Location: 's Hertogenbosch, Netherlands

Re: Limiting extensions

Postby David Weller » 24 Feb 2005, 13:20

Hi Tony,

I think you may be mistaking about what I'm doing
[which may ultimately be my mistake]

After applying all possible 'fractional' extensions, I simply check to see if the new 'sum' meets or exceeds ONE_FULL_PLY

If it does, I set ext = 1 and extend that move

the line ext_move -= ONEPLY simply strips away all but the fractinal remainder, which is passed on to the next recursive search

It seems this all works, but no better than my original method of simply extending one ply if any of the conditions were met
User avatar
David Weller
 
Posts: 135
Joined: 26 Sep 2004, 20:30
Location: USA

Re: Limiting extensions

Postby Pallav Nawani » 24 Feb 2005, 14:21

David Weller wrote:Hi Tony,
It seems this all works, but no better than my original method of simply extending one ply if any of the conditions were met


Agreed. That was my experience as well.
User avatar
Pallav Nawani
 
Posts: 147
Joined: 26 Sep 2004, 20:00
Location: Dehradun, India

Re: Limiting extensions

Postby Tony van Roon-Werten » 24 Feb 2005, 17:50

David Weller wrote:Hi Tony,

I think you may be mistaking about what I'm doing
[which may ultimately be my mistake]

After applying all possible 'fractional' extensions, I simply check to see if the new 'sum' meets or exceeds ONE_FULL_PLY

If it does, I set ext = 1 and extend that move

the line ext_move -= ONEPLY simply strips away all but the fractinal remainder, which is passed on to the next recursive search

It seems this all works, but no better than my original method of simply extending one ply if any of the conditions were met


Hi David,

I think I see now. You could still be extending more than 1 ply, but you limit the amount you're over extending.

Then you limit it again by not taking the "overextension" into account when probing fe the hashtable ( since the overextension isn't in depth yet)

I never tried it this way. I'll see if I have some time left...

cheers,

Tony

Addition: No I wont. I pass the depth with fractional component in it to the next ply. It would take to much changes to change that.
Tony van Roon-Werten
 
Posts: 99
Joined: 02 Oct 2004, 15:31
Location: 's Hertogenbosch, Netherlands

Re: Limiting extensions

Postby Tord Romstad » 24 Feb 2005, 18:57

Hi Ross!
Ross Boyd wrote:By the way, only allowing one ply extensions makes the single-reply-to-check extension a little problematic. I detect being in check AND single-reply to check usually at the same node. Rather than double extend this node, I pass the single-reply extension as a parameter to the next node... and extend there. Ideally, I'd rather extend moves that GIVE check and then extend single replies at the next node.

Why not do just that? What is your reason for not extending the checking moves rather than check evasions? It seems to me that your alternative would introduce too many tactical oversights at the last ply before the qsearch.

Tord
User avatar
Tord Romstad
 
Posts: 639
Joined: 09 Oct 2004, 12:49
Location: Oslo, Norway

Re: Limiting extensions

Postby Ross Boyd » 24 Feb 2005, 22:10

Hi Tord,

Why not do just that? What is your reason for not extending the checking moves rather than check evasions? It seems to me that your alternative would introduce too many tactical oversights at the last ply before the qsearch.


Exactly. The primary reason is lack of quality programming time.

I do 1 ply of generating quiet checks in qsearch (if there are no capture beta cuts) so that helps a little.

But I'll give your method a try, hopefully soon, it sounds like it will give her a little boost.

Thanks for the tip!

Ross
User avatar
Ross Boyd
 
Posts: 83
Joined: 26 Sep 2004, 23:07
Location: Wollongong, Australia


Return to Programming and Technical Discussions

Who is online

Users browsing this forum: No registered users and 16 guests