Author: Robert Hyatt
Date: 08:51:05 02/20/02
Go up one level in this thread
On February 20, 2002 at 02:48:16, Gian-Carlo Pascutto wrote: >On February 19, 2002 at 23:27:00, Robert Hyatt wrote: > >>OK if you talk about null-move I assume _nobody_ says that it doesn't add >>its own unique errors into the search. I certainly see enough of them. :) > >Perhaps. But you are still using it... Sure. But would you prefer to play with your program doing 13 ply searches _with_ null move, or 13 plies _without_??? There is no question which would win more games. I have run the experiment already... > >>No... but a failed pruning rule can and will eliminate a critical move >>that skews the scores badly. The more errors you make, the more the >>score gets skewed. An error at ply=2, for example, is simply critical >>and will result in a very bad error. > >It should be the nature of a good pruning rule that such a mistake >will alost never happen. i.e. that it is more reliable near the root >This is true for most rules in use now, either by making the decision >based on more data (nullmove) or simply by not using it near the root >(futility pruning) > null-move is not a forward pruning algorithm. Not in the context of any AI reference to forward pruning. Because null-move doesn't just throw out moves ad hoc, it simply searches to a reduced depth instead, which is significantly different from "forward pruning" or "selective search" as the terms are traditionally used. Forward pruning is entirely different, and is based on the idea of generating the set of moves for a position and throwing some of them away with no searching of any kind. There is great danger there... >>by definition any forward pruning is bad, in terms of introducing error. >>Yes, you might gain more than you lose with some rules. But trying to >>make the tree selective enough to reach that 60 ply repetition is certainly >>going to push the error rate into the stratosphere.... > >This is very much a Vincent-ian argument. It's not because you can't >do it that it is simply impossible. > >For one, Chess Tiger seems to be searching nowadays with a branching >factor that's very close to 2 and sometimes even below that. It's >obviously not getting any kind of huge error rate that causes it to >lose each game by playing losing blunders. Far from it, even. I doubt it is getting a branching factor of 2 where it is trying to extend wild checking lines to 60 plies. Can't possibly happen. That was the point. There are _lots_ of lines in the Kf1 analysis, not just one very narrow line that goes to 60 plies. There are a _bunch_ of them. > >I see no reason not to believe this can't be pushed further down. > >Now think about it. Once you consistently go below 2, each simple >speedup will result in more and more plies. > And as you go below 2, you are doing so at great risk of making gross errors as well. >You won't need to see the full 60 (or 36) ply in every variation >here. The draw by repetition is going to have a lot of checks in >it which should allow a program to find it faster. > Yes you do if you are trying to _prove_ that Kf1 draws. And in the case of this position, if you have looked at it, the killer is that way out near the tips there are "quiet" (non-checking/non-capturing) moves that tend to lop the search off at that point. And this hides the perpetual quite well. And when you start extending when not in check or anything else, you are _never_ going to have a BF of 2 or less... It is the _quiet_ moves that are the problem in this particular game position, not the repeated checks which are not hard to handle at all. But if you have to search a string of checks, followed by two consecutive quiet moves, followed by another long string of checks, today's searches simply are not capable of doing that. At least in finite time searches... >I'm assuming a 30 ply nominal search might suffice. That is not so >far out as you might think. Seeing it's at 22 ply after half a day, >it'll need (2^8) / 2 = 128 days as a rough estimate. Except for the quiet moves, you would be right. But they happen way out into the tree, say at ply 50. Which means you have to reach that depth with some search left over to catch the quiet moves and get beyond them into the checks again. Not easy at all. In fact, nearly impossible. > >>It has been around forever (version 1 and 2 and 3) version 1 was R=1, non- >>recursive. Version 2 was R=2 recursive. Version 3 was R=2~3 I currently >>use it. Version 4 might be pure R=3 as some are trying... But they are >>all very closely related... >> >>Whether there will be a revolutionary new approach is a guess... I hope so, >>but I doubt it... > >I would say it has already arrived. Those darned pro's are just >not sharing it :) > >-- >GCP That may well be. Or not...
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.