Author: Uri Blass
Date: 16:10:07 05/04/03
Go up one level in this thread
On May 04, 2003 at 18:49:44, Sune Fischer wrote: >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. The reason is simple. Correct knowledge is not always better because the order of evaluations is also important.
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.