Author: Wayne Lowrance
Date: 18:49:22 12/23/03
Go up one level in this thread
On December 23, 2003 at 18:14:43, Uri Blass wrote: >On December 23, 2003 at 16:01:35, Wayne Lowrance wrote: > >>On December 23, 2003 at 10:17:50, Uri Blass 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 >>> >>>The point is that more smart elements can improve the result and it seems that >>>by neglecting a lot of important stuff you limit your possibilities to improve >>>the evaluation. >>> >>>Finding the correct weights or finding ideas of defining more cheap stuff is one >>>way to improve the evaluation but not the only one. >>> >>>I do not claim that your evaluation is relatively bad because Junior is a fast >>>searcher but it can be better if you use some expensive stuff and decision not >>>to use it suggest that speed is not more important for you than better >>>evaluation when you need to choose between them. >>> >>>Uri >> >>Excuse me Uri but you are making a fuss against Amir, whose program clearly >>demostrates his better understanding of his program if not chess programming >>than you and your whichamacallit program whose name I dont remember. > >I did not do a comparison between Movei and Junior and I do not see how it is >relevant for this discussion. > >I see that I also make a mistake in my statement and one not should not be >written. > >My point is only that it seems that speed is more important for Amir than better >evaluation when he has to choose between the 2 things because I believe that >Amir can write a code to detect trapped pieces in the evaluation and the main >problem for him is speed. > >Note that I also did not write a code to detect trapped pieces but I have not >many years of experience in chess programming like Amir. > >Uri Ok, I understand you
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.