Author: Robert Hyatt
Date: 05:45:06 08/02/01
Go up one level in this thread
On August 02, 2001 at 07:32:41, Vincent Diepeveen wrote: >On August 02, 2001 at 03:44:01, Janosch Zwerensky wrote: > >>Hi all, >> >>I read some time ago that Deep Blue wasn't using heuristic game tree pruning >>methods (like, for example, the null-move technique). >>Since null-move was known when DB was around, can anyone here tell why the DB >>team decided not to use it (or wasn't able to do so)? > >There are a number of reasons > a) IBM focussed upon nodes a second, search depth was not important, > the only PR argument was their machine was FASTER than anyone elses. > b) they searched 12 ply which was deeper as anyone else anyway > c) nullmove back then was considered dubious, scientists didn't know > much from it What are you talking about in (c)? in 1996/1997 null-move was as well- understood as it is today... > d) look at the historic picture. The deep blue designers were busy > improving their machine. Well they could search deeper as the previous > machine could, so why look to for sure tough to figure out things > like nullmove? > e) in hardware using nullmove is nowadays easier as it was back then. > Back then timing issues were of major importance. Eh? That doesn't compute at all. Hardware design today is just as it was 10 years ago. Only the circuits are smaller and the clock frequencies are faster, which has made things more complicated, not easier... > f) Important to realize is that the processors didn't even USE > hashtables. Important to remember that they _could_. DB2 had the hash probe stuff in it, but Hsu had no time to design/build the multi-ported memory to provide a hash table for the chess processors. But they _did_ use it in software, which was the first 10-12 plies plus extensions... that isn't horrible. > >Bob has given a very plausible explanation. Hsu was busy getting >hashtables to work, but did run out of time to get them to work on >chip. No... he got them to work on the chess processor. But he didn't have time to build the memory units for each DB2 circuit board. He barely got DB2 itself running for the second match. > >I can completely imagine Hsu here. > >IMHO hashtables are more important than nullmove is, >nullmove only gets important when all the things are well done. > >Why get nullmove to work when hashtables aren't working yet? > >We all do as if Deep Blue was a well tested and well playing machine. >It was not! > >It was not even finished! > >What played kasparov were a few bare chips without hashtables even! > >No one, including me, could imagine that Kasparov would play a few games >in his life that bad! > >Of course, Kasparov is just human, IBM had said all kind of things like >that this would be the last match they would play, "BECAUSE DEEP BLUE >ALWAYS LOST". IBM never said that. I don't think they were convinced they would win this match either, and you could bet there would be another. Otherwise they would have stopped after match 1. > >It's hard to see this machine as a simplistic thing without political >interests. Instead the most important reasons are completely forgotten >by time: IBM focussed upon NPS. > >There were even artificial scientists suggesting >short after the match: "perhaps intelligence is nothing as >a combination of a simple algorithm and a huge processing speed". > >Though i completely disbelieve those scientists, the only interesting >thing for Hsu to get to work was a machine getting more nps as any other >machine (his previous version) got. > >He made such a machine. > >In 1997 i was even completely made a fool at when i suggested that >it was possible with nullmove to search deeper with a huge >nps like DB got, because of a better branching factor when using >a combination of nullmove and clever designed hashtables. > >The thread was called something like: "getting 18-20 ply". > >I claimed a branching factor which was way under the 'knuth theoretical >branching factor'. In 1997 no one had a good branching factor >except me and some others who very dubiously forward pruned. > >This because no one used intensively hashtables in combination with >nullmove. > >Of course first nullmove was made ridicioulous, then my claim that >it would be possible to get 18-20 ply with so many nodes a second >(200 million). > >You should seek for those messages posted at rec.games.chess.computer >during those years. > >Only the furious replies from scientists who still are furiously >commenting here with different arguments in CCC now at different >threads, only those furious replies back then will give you >an impression how weird they back then would have considered >using a combination of nullmove and hashtables as the way to go. > >Using nullmove was not even taken seriously. > >The big increase in speed of todays processors and the deep blue >logfiles showing it got 11 to 12 ply in most positions, also clearly >showing no depth difference between far middlegame where there are >loads of transpositions, and start of game where there are loads of >branches to research (search depth is >obviously showing that deep blue didn't use >hashtables in hardware processors); if you compare that small search >depth difference between programs using hashtables (with or without >nullmove, whatever) you will clearly see the huge difference >already. > >Note that back in 1997 things like multi-probes as we all use, >were also not used by many persons. In fact i only recall Bob mentionning >them he used them in cray blitz. > >Best regards, >Vincent > > > >> >>Regards, >>Janosch.
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.