Winboard Forum

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 ]

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

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

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

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

Hi Sven, p27 probably means pawn to the 7th rank.

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

Sven

Forgive my laziness please,
Uri is correct
I have a bad habit of using short cryptic names

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

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

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.

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.

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

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