Author: Vincent Diepeveen
Date: 06:03:41 08/02/01
Go up one level in this thread
On August 02, 2001 at 08:45:06, Robert Hyatt wrote: >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... Can only take your word for that :) > > >> 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. I don't doubt it was used the first 6 ply in software. > >> >>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. In fact they even had said they would attach it to the internet after the match. > > >> >>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.