Author: Sune Fischer
Date: 15:49:44 05/04/03
Go up one level in this thread
On May 04, 2003 at 17:41:30, Dieter Buerssner wrote: >I agree with Uri, that there are many cases, where one can avoid the (time >overhead induced by) TB-probing. For example almost all 4 vs. 1 TBs would fit >this. I am not convinced. I thought a long and hard about how to implement that imfamous draw KBP-K, where pawn(s) are on the rook file and bishop of the wrong color. The problem is not in detecting the specific case(s) as such, the problem is in detecting this along with possibly 30 other common patterns, and to do it quickly enough to not slow down the engine significantly. This is where the tables have an advantage IMO, it is one check that checks for it all. And if you use enough cache TBs are quite fast. I don't see how a similar trick can apply to general patterns, because they are so vaguely defined compared to TB positions. I think the best one can do is to build a kind of log2 pattern detector, if you know what I mean. Perhaps it's not overly expensive, but I still question its value if the engine is already running with TBs, certainly there must be redundancy somewhere. >But, one really has to be careful. I think, knowledge, that is correct in >only 99% of the cases will hurt here. Sooner or late the opponent will find the >hole in your knowledge (I have seen practical cases, where engines lost because >of seemingly clever knowledge, that did not apply exactly, while a stupid engine >would have easily reached a draw, even without any understanding/knowledge of >the position). I think "bad" is a relative term here. If it helps in 99% of the cases and loses in 1%, I'd still use it. :) >TBs can help, to design perfect knowledge. One can test the "knowledge function" >vs. the perfect knowledge of TBs, and find any exception. I did this for the >latest version of Yace, for some easy positions with 4-men. For example N vs. P. >Typically, the N cannot win, but sometimes it can (when the P is a rook P and >the K is in a bad pos). With some rechecking against TBs, it was not difficult, >to find rules, that include all exceptions. Note, that this does not mean, that >the engine can statically evaluate all positions correctly. But it can delay >pruning, which will be enough in many cases (and will be not worse, than not >trying to "apply" the knowledge anyway). > >There are quite a few other subtle points, that can be considered here. Recently >an interesting position was shown in this forum, where a TB equipped engine >refused to take a pawn in KPPPKR, and thereby lost. Similar other scenarios are >possible. Was there ever offered an explanation as to why that happened? I certainly think it is a stretch to draw the conclusion that TBs are bad because there is an exception. I think it'd be more rewarding to find out why they choose a faulty drawing move, to understand why the TBs mess it up. Without TBs or any other kinds of knowledge the engine has (I bet) a positive score for the rook side, and that is just as bad, in principle. -S. >Regards, >Dieter
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.