Author: Volker Böhm
Date: 08:27:08 04/20/04
Go up one level in this thread
On April 20, 2004 at 11:17:02, Fabien Letouzey wrote:
>On April 20, 2004 at 10:52:39, Volker Böhm wrote:
>
>>Hi,
>>
>>when looking at crafty I love his nearly perfect PV he returns after search. I
>>have implemented a PV collection (that I think is bug-free) but it hasn´t the
>>same "quality" i.e. it often does not show the PV to full depth.
>>There are three problems:
>>1. A "exact" hash hit (not too often in PV, crafty has the same problem)
>>2. Leaving the initial search window. A new search with wider window will bring
>>the right PV.
>>3. A problem with hash, PVS and fail-soft. Crafty hasn´t got this problem as it
>>is more "fail-hard" then my engine.
>>
>>My problem is:
>>
>>I am only adding moves to the current PV if their value is inside the current
>>search-window.
>>
>>I use PVS. In PVS I search again if the "current move" is better or equal than
>>current alpha and it is not a fail high (> alpha & < Beta). (slightly
>>simplified, yes you need to find one move > alpha first)
>>
>>When searching "current move" again, now with Bounds -Beta, -Alpha, the hash
>>will allmost everytime have an entry at the next ply. The entry will be a
>>"upper-bound" entry (from the past fail low leading to a score > alpha at
>>current ply).
>>
>>I use lower or higher bounds from hash to reduce the current window. An
>>upper-bound entry will reduce beta to this entry.
>>
>>If the new search of "current-move" does return exactly the same score as last
>>time it will fail-high against the reduced beta.
>>
>>Consequence: neither the first nor the second search of this PVS move is stored
>>in the PV. Fail hard solves this problem in most cases. But in my tests I had
>>additional nodes if I implement a bit more fail-hard.
>>
>>Has anybody a good solution for my problem? I don´t want to increase nodes
>>searched just to get a better PV. Hope I explaned the problem well!
>>
>>Greetings Volker
>
>I don't know of any solution that does not use larger windows, sorry.
>
>I fail to see, however, how fail hard solves the problem:
(our example below) If you search with window [+8,+9] and get +10 as result then
you can store +10 to hash ("fail-soft-soloution") or +9 (== beta)
("fail-hard-soloution"). In my test suite this "fail-hard-soloution" was good
enough to get allmost everytime a good pv. But additional nodes! It is too
significant to live with.
>
>Say at a PV node the first move gets value +8. You search the next
>move with window [+8,+9] and get +9. You re-search with window
>[+9,beta] (same result if you use [+8,beta] then shrink the window
>using the hash table). Say you obtain +9 again (that's the exact
>value of the second move). I don't see how you can get a complete PV
>then.
In this case fail hard and fail soft is identical as the fail soft == beta and
not above.
>
>I suggest you try without the window-bound update. I know you don't
>want to do that, but measure how many more nodes you search :)
>
>Fabien.
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.