Author: Fabien Letouzey
Date: 03:34:29 03/11/04
Go up one level in this thread
Uri, > The lack of knowledge in crafty is also real. > Crafty does not know things like ETC. Bob specifically mentioned in posts that he tried ETC and discarded it based on testing. So the "lack" of ETC cannot make Crafty weaker. In my experience ETC is fine if used "far away" enough from the leaves. Most of the time the slightly better BF only barely compensates for the loss of speed, but in some endgames with locked pawns I believe ETC can help a lot. Also I think the more time the more interesting ETC is. > I do not think that it is slow and it is simply crafty that is fast. > There are a lot of programs that search significantly less nodes per second. I do think it is slow based on how I could make the code faster. OK, maybe only 50% faster. But it would make the code hard to modify in the future. I will care about speed only when I have a clear design in mind. Actually after version 1.0 is released next week I intend to "unoptimise" the code by removing complex function that only slightly improve speed, so I can experiment with new things easily. > People often claim that small evaluation should be a problem at slower time > control so if it has little evaluation it cannot do better at longer time > control. I am only trying to understand what "search" really does. That is different from saying "stupid eval is the way to go". > What is your opinion about it? > Is it a wrong opinion and chess is simply a search based game when almost every > hole in the evaluation can be covered by searching few plies deeper? How are you expecting me to answer a question even commercial authors don't agree about? Compare Diep with Chess Tiger; same design? I don't think so. Diep was stronger 10 years ago than my program will ever be, how could I say a good eval is useless? Uri , can you understand that a chess program can be designed for other reasons that beeing the strongest possible? I have written evaluations before, it is too boring for me. I want to study search, and apply things to other games as well. I will add knowledge to Fruit, but only to "fix" the biggest problems. I don't especially believe this is the best way to obtain a strong program. > I knew from the results of olithink that programs can do well even with small > evaluation but the results of your program suggest that olithink was not close > to the best that it is possible to do with small evaluation and I suspect that > it is even possible to be better than Crafty with your little evaluation(after > all I guess that you do not use all the good techniques that were mentioned and > for example you do not use history based pruning when the idea is to prune moves > that almost always failed low based on the history tables by searching them to > reduced depth,not to mention that you do not use pruning based on evaluation or > extensions except check extensions). Yes, I use only null-move pruning. There is nothing in my search that is not known by most programmers. Actually the few differences there are might be hurting strength, like I never "hash cut" at PV nodes (I only read the best move) so that my PV is never truncated. Also I use a "safe version" of PVS, where my research windows is the "full" [alpha,beta] instead of [value,beta] where value is the result of the null-window search. I also don't update alpha or beta based on the value in the hash table. In the case of Fruit, I believe its lack of tactical extensions hurts a lot in fast games. I expect that this matters less as slow time controls. This is unrelated to evalution. Fabien.
This page took 0.01 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.