Computer Chess Club Archives


Search

Terms

Messages

Subject: Re: new idea on managing time using depth reduction at root

Author: scott farrell

Date: 02:00:47 02/08/03

Go up one level in this thread


On February 08, 2003 at 03:25:06, Tony Werten wrote:

>On February 08, 2003 at 00:50:22, scott farrell wrote:
>
>>My idea relies on an underlying use of PVS search (principal variation serach),
>>an aspiration window, and IID (internal iterative deepening).
>>
>>When searching the root position, I search the first move as per normal.
>>
>>Then I search all remaining root moves at depth-1, basically everything gets a
>>reduction. This speeds the already fast PVS search. If any of the PVS searches
>>at root fail require a research, I research without the reduced depth.
>
>I do something like this in XiniX, but since I don't like reductions, I do it a
>little different.
>
>I add a ply to the best move.
>

I think at the end of the say it is EXACTLY the same. Whether you add a ply to
the 1st move, or take a ply off from every other move, its the same.

thanks for your comments.

I really do beleive this is a powerful idea !!!

>My reason for doing this: I don't mind if the engine overlooks something, but if
>it looses because the moves were played exactly as it expected then I get upset.

This is exactly what prompted me to invest time in this, loosing a game when it
followed half way down the PV. And later analysis showed that about 1000 nodes
more were needed to see a fail low .....

>
>If the first move seems good then 2 things can happen:
>A It isn't good at higher depths
>B Another move is better.
>
>B won't make you loose a game ( It just wins slower ) A can kill you. I prefer
>to invest more time to avoid A than to get B
>

There is a big different between not loosing and trying to win !!!!

thanks again

Scott

>Tony
>
>>
>>If at any time I fail low at root without a PV move already, then you panic and
>>add time etc, and dont do any depth reductions.
>>
>>If you fail high, I often just take the move if its near to the time allowed for
>>this move, especially if its value is more than our last move on the board.
>>
>>The idea is based on a few thoughts:
>>"why do you try ply 9 when you already have a nice move on ply 8"
>>"are you trying to ensure the move is safe?"
>>"are you trying to find a better move?"
>>
>>I think proving your move is safe is far more important. And that is what my
>>idea above does. It spends more time on checking that your move is safe, rather
>>than looking for a better move. This really helps, when there are 2 candidates
>>moves, and they are very close in score, and your engine spends lots of time
>>flip-flopping between them as best. My idea disregards the second, until it can
>>be shown it is much better.
>>
>>When you have finished searching say ply8, you have really only searched ply8
>>for the best move, and ply7 for everything else, unless you found a problem with
>>the best move and panicked.
>>
>>In positions where you have 1 clear good move, things really get an amazing
>>boost. In positions with lots of traps, it takes just as long as normal (ie. no
>>slower), but finds the traps more quickly, and during a game gives you the fail
>>low more quickly in order to allocate more time.
>>
>>I implemented this in chompster, and it seems to have had no drawbacks. It has
>>been averaging around 2450 on ICC in recent weeks, pretty good for Java !!
>>
>>This will be especially useful for 'newer' engines that arent real good on time
>>management, and only search full plies at the moment - this sort of allows you
>>to search partial plies when it is safe to do do.
>>
>>Let me know what you think, and if you might give it a try in your engine.
>>
>>Scott



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.