Author: Uri Blass
Date: 02:36:09 12/25/03
Go up one level in this thread
On December 25, 2003 at 05:20:55, Vasik Rajlich wrote: >On December 24, 2003 at 10:54:45, Christophe Theron wrote: > >>On December 23, 2003 at 21:44:07, Robert Hyatt wrote: >> >>>On December 23, 2003 at 18:25:26, Christophe Theron wrote: >>> >>>>On December 23, 2003 at 09:49:27, Anthony Cozzie wrote: >>>> >>>>>On December 23, 2003 at 08:50:51, Amir Ban wrote: >>>>> >>>>>>On December 23, 2003 at 08:09:34, Uri Blass wrote: >>>>>> >>>>>>>On December 23, 2003 at 06:47:18, Amir Ban wrote: >>>>>>> >>>>>>>> >>>>>>>>Thanks for running this match and for the interesting commentary. >>>>>>>> >>>>>>>>My point in playing this match was never to show how weak crafty is, but >>>>>>>>something different: Too many programmers and posters in this forum take the >>>>>>>>speed issue way too seriously. They don't understand the importance of >>>>>>>>evaluation, and when they do think about it, they think it's about pawn >>>>>>>>structure and a few super-rare endgame tableaus. >>>>>>>> >>>>>>>>I also needed to check that I've not been wasting my efforts in the last few >>>>>>>>years. >>>>>>>> >>>>>>>>Merry Christmas and Happy Hanukka, >>>>>>>>Amir >>>>>>> >>>>>>>I do not claim that evaluation is not important but my opinion is that search is >>>>>>>not thing that is less important. >>>>>>> >>>>>>>I also know that inspite of the fact that you say that evaluation is important >>>>>>>your evaluation takes only 20% of Junior's time(I do not know about latest >>>>>>>Junior but I know about previous post of you). >>>>>>> >>>>>> >>>>>>Less than 10% in most positions. >>>>>> >>>>>> >>>>>>>How is it possible? >>>>>>> >>>>>>>Did not you find important things to evaluate that it is simply impossible to >>>>>>>evaluate them fast? >>>>>>> >>>>>> >>>>>>There are many things I can do basically for free in my framework. There are >>>>>>things that break the model, and either are neglected or if considered critical >>>>>>get done outside it. >>>>>> >>>>>> >>>>>>>For example let talk about pieces that are in danger of being trapped because >>>>>>>the opponent control every square that they can goto. >>>>>>> >>>>>>>There are cases that you need to search many plies forward to see by search that >>>>>>>they are really trapped but a good evaluation should detect the danger. >>>>>>> >>>>>>>Correct me if I am wrong but I guess that you do not evaluate this information >>>>>>>in every node that you evaluate otherwise you cannot be faster in nps than the >>>>>>>opponents. >>>>>>> >>>>>>>Did you consider to evaluate this information or do you think that this >>>>>>>information is not important? >>>>>>> >>>>>> >>>>>>I do this for some important special cases. Not in the general case. It's hard >>>>>>for me to guess how productive that would be. >>>>>> >>>>>> >>>>>>>I think that evaluating expensive information in part of the cases is probably >>>>>>>the best practical idea. >>>>>>> >>>>>>>Based on my understanding Rebel is using that idea when it evaluates every node >>>>>>>before qsearch by full evaluation and use lazy evaluation after it when the lazy >>>>>>>evaluation can miss only factors that were not relevant before the qsearch. >>>>>>> >>>>>>>Do you use a similiar idea? >>>>>>> >>>>>> >>>>>>No. >>>>>> >>>>>>You are confusing between the evaluation elements and its result. Both are >>>>>>important, but it's still true that your evaluation of a position can use a lot >>>>>>of smart and correct elements and be totally off, and it is equally true that it >>>>>>can be right though neglecting a lot of important stuff. >>>>>> >>>>>>Amir >>>>> >>>>> >>>>>It seems like you and Christophe have some tricks up your sleeve. He's been >>>>>making comments like this for some time about his new 'Fugu' thing. It looks >>>>>like I'm going to have to do some serious thinking :) >>>>> >>>>>anthony >>>> >>>> >>>> >>>>The basic thinking with Fugu is that I'm fed up of evaluating every position. I >>>>want Chess Tiger to be able to understand which positions do not need more than >>>>a pure material evaluation, and which positions must be evaluated positionally >>>>very precisely. >>>> >>>>Another idea is to have an engine that performs two searches at the same time: a >>>>very deep, full speed tactical search, and a less deep, very slow positional >>>>search. The problem is what to do with the two results when they differ... :) >>>> >>>> >>>> >>>> Christophe >>> >>>Look at Shaeffer's stuff on Sun Phoenix. He had problems getting reasonable >>>efficiency on a distributed search with an old 10mbit ethernet LAN, so he >>>split the system into two parts, one that searched normally, one that did a >>>fast tactics-only search. And he reached the same conclusion. What to do >>>when they disagree. Or when the positional search says "play X" and the >>>tactical search says "X sucks". :) >>> >>>I don't like the concept myself, but perhaps it can work. >> >> >> >>Actually both searches would not be separated. They would be performed by the >>same algorithm. So you do not get two separate results as my previous post >>implied. >> >>The tactical and positional searches are completely interwoven, and information >>extraction happens everywhere in the resulting tree. >> >>So the final decision is not between move X and move Y. The final decision takes >>into account thousands of microscopic positional vs tactical results, where you >>add a positional score for depth 0 to a tactical score for a depth of 4 or 5 for >>example. The problem is that you can add a positional score that says that your >>queen is extremely well positioned, but the tactical search has already found >>that this queen will be exchanged 2 plies later. >> >>While it may sound completely screwed, I think it makes *some* sense (maybe not >>enough to be a successful idea, but who knows). >> >>The basic idea is to have a positional, not very deep search, but that is almost >>completely free of tactical mistakes. >> >>The potential of the idea is to allow for a more complex and expensive >>positional evaluation without losing tactical depth, which is as experience >>shows absolutely crucial in computer chess. >> >> >> >> Christophe > >Interesting. You could also prepare some data structures in the positional >search and use them in the tactical search, a sort of root-node pre-processing >repeated in mid-search. > >What I'm curious about is, how expensive is a really heavy evaluation? I've put >into my engine a rather bloated eval and some conservative rules for doing only >lazy eval and still the eval takes up barely over 50% of the total search time. 50% is a lot. Junior is using less than 20% >This number seems hardly worth reducing - even reducing it to zero would only >double the nps, which is less than half an extra ply. It suggests that you should improve your search first. It seems much more >important to improve the eval and to guide the search better than to worry about >a factor of 2 in the nps. > >Maybe I underestimate the size of a really good eval. (Mine is about 4 months >old.) > >Vas No Maybe you overestimate the gain that you can get from a bigger evaluation. This does not mean that evaluation is not important but the quality of the evaluation is the important thing and not the size. Uri
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.