Author: blass uri
Date: 15:53:08 07/18/00
Go up one level in this thread
On July 18, 2000 at 18:17:45, Robert Hyatt wrote: >On July 18, 2000 at 14:46:01, blass uri wrote: > >>On July 18, 2000 at 14:13:09, Robert Hyatt wrote: >>>>>That is the main difference I see. We _all_ saw the king safety/blocked >>>>>position problem in Dortmund. We didn't see any such problem in DB'97. >>>> >>>> >>>>It does not prove that the evaluation of DB'97 was better about king safety. >>>>I guess that with 200M nps Junior could find better moves and avoid the king >>>>attacks in the games. >>> >>> >>>There you are simply wrong. No matter how deep you search, there is _always_ >>>a position that doesn't expose the tactics until one ply deeper. >> >>I agree that there are positions that Junior will fail against king attack but >>the practical question is if humans could practically go to these positions if >>Junior was faster(200M nodes per second). > >We have several copies of Junior (and others) running on ICC, including more >than one deep junior. I have seen GM players achieve these kinds of attacks >in very fast games... Where the GM has little time to think and has to >'intuit' everything. And intuit they do... It does not prove that they could create the same king attacks if Junior calculated 200M nodes per second. > >There are many positions search won't solve. There are many positions that >evaluation won't solve. There is room for both in a chess engine, and _both_ >are important when playing players at the top level of chess... I agree that there are many positions that search do not solve but I believe that these positions will be rare in games of Junior if it searches 200M nodes per second. There are many fortress positions that computer do not understand but it does not help humans in games because they usually cannot get these positions. > > > > > >> >>I believe that in the games against kramnik and piket Junior could survive. >>I do not say that it could always survive but there is a good chance that it >>could also survive in 6 game match against kasparov assuming 200M nps and that >>you will not see king safety problems. >> >> If your >>>evaluation doesn't recognize trouble without seeing it in the search, then it >>>is going to make mistakes. >>> >>>I have lots of details about what kinds of things DB's eval had for king >>>safety. I can tell from the speed, that DJ doesn't do the same things at >>>all. Nor do I. >> >>You cannot know only by the speed. >>You need to know the source code in order to know. >> > > >I know by the speed. Because I am experienced enough to know what is possible >with today's hardware and what is not. Ask Amir if he knows which pieces are >attacking squares adjacent to the king. Which pieces are attacking indirectly >in battery. Which pieces are attacking squares adjacent to the squares next to >the king. Which files around the king are open (probably yes). Which files >around the king _can_ be opened. The list goes on. Much of that is very >time-consuming to calculate. If you do it in software. It becomes instant if >you do it in hardware. The question is if calculating all this list in all the nodes is so important. It may be possible to calculate the exact evaluation only in small part of the nodes and to learn from it another evaluation function that is more simple and gives almost the same scores. > >If you do all of that in a current engine, you get smashed by other computers, >because they don't attack, you waste all that time looking for attacking >ideas, and you go so slow they toast you tactically. Isn't this the same >program we were talking about not having _any_ quiescence search at all? >Why do you think it doesn't have one? > > > > >>I believe you that Deeper blue evaluates more things but the question is if it >>evaluates the correct things. > > > >One thing is absolutely certain. If you evaluate less things, you definitely >miss some correct things, since they aren't there at all. > > > > >> >>> Nor does Hiarcs. Or any other program, fast or slow. >> >>You need to know the source code of all the other programs in order to know it. >>It is possible that other programs can evaluate the same thing faster because of >>an idea that Hsu did not think about. >> > > >You overlook the obvious. Hsu does it _all_ instantly. There is no "faster >way" in his hardware to do anything. It is all done at warp-9.999 speed. He >only has to figure out what he wants to do, then figure out how to put it in >hardware so that the cost is zero. We have to figure out what we want to do, >then if we can afford the cost of doing it. Those are two totally different >worlds to work in. I believe that chess system tal evaluates everything that the programmer wanted but I may be wrong. 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.