Author: Dann Corbit
Date: 11:38:48 08/29/05
Go up one level in this thread
On August 29, 2005 at 12:05:33, Robert Hyatt wrote: >On August 29, 2005 at 11:55:17, Gian-Carlo Pascutto wrote: > >>On August 29, 2005 at 10:05:41, Robert Hyatt wrote: >> >>>The problem is that you then introduce errors. I only probe (on the quad 875) >>>when a capture takes the board to 5 or less pieces, and I have all 5-piece >>>tables on that box. I don't probe in the q-search at all, although some do and >>>I used to. I can't see how you could reduce that without introducing >>>significant errors. >>> >>>Years ago I used to limit the depth at which I probed, to keep the NPS from >>>dropping too far. And saw too many mistakes where it would push the critical >>>capture beyond the probe horizon, so that it could still think it was winning or >>>whatever. And it would enter a forced line because of that, thinking it was >>>winning, when it was forcing a draw... >> >>1) I haven't seen this effect. >> >>2) Should it work as you describe, it would still happen. I looked at Crafty and >>you limit probing to <= iteration depth, you can search a lot deeper, especially >>with some spite checks or pawn pushes. >> >>3) What about 6 men? >> >>-- >>GCP > >I am using almost all 6 man endings on my dual xeon, and am not seeing anything >worse than what I saw with 5's only. The severe slowdowns are rare, but happen >either way... > >Yes I limit the probe depth somewhat. My question was, how could I safely limit >it further? Every ply it is limited has an associated risk. I still see >positions where the q-search thinks it is reaching a won position, but it is >not, because I don't probe out there as some do... > >I tried a _bunch_ of different limiting schemes over time, including one >"adaptive" scheme that dynamically limited the depth-to-probe-at based on the >NPS of the search. It would notice an excessive slow-down and reduce the depth >at which probes were done to avoid losing too much. > >Turned out to cause other problems related to hashing and EGTB scores... It seems to me that the bitbase approach is a good one. For each of the tablebase files, convert to won/loss/drawn/broken and those can probably be loaded into memory for a much cheaper cost. Then, perhaps you could probe only the pv nodes and all the root node positions which should be pretty cheap. Just a thought.
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.