Did a bug in Deep Blue lead to Kasparov's defeat?

[hyatt]

Most of the engines find it in a few seconds and then switch back and forth a lot.
I guess that deep blue may well have switched back to the queen move instead given more time.
I also guess that the queen move was not as bad as Kasparov thought and the computer would have done quite well, even if Qb6 had been chosen.
I also guess that Kasparov had prepared a trap for the queen move using other computers as sparring partners. I guess further that all the computers he tried played Qb6 and he beat all of those computers. But none of the computers he had access to could compute 200M NPS.

I really think that Kasparov played shockingly well and that he is probably the best human chess player of all time (though RJF had a remarkable peak period and Capablanca was also a freak of nature).
{Not to be confused with my favorite chess player of all time (Yasser Seirawan).}

I did not care for Kasparov's behavior in connection with the match, but he's the only man on earth that knows the kind of John Henry pressure that he was under and there is no saying whether or not anyone else would buckle under such a load.

A couple of points.

1. Yes, I agree that the two moves are close, and which move is played is more a function of search time limit than anything else, because as I ran this thing, I saw similar flip-flopping...

2. DB was different from others of today in terms of the singular extension idea. Nobody does it like Hsu did. Too expensive and too complex. One only has to read his paper to see all the tricks they had to employ (things like the sticky transposition table to make sure that once a move was declared to be "singular" it kept that for a couple of extra plies even if the singular condition was not satisfied, to prevent instability in the search.

they could see some things extremely deeply. today we see much deeper in terms of "plies" reported, but with reductions and forward-pruning, neither of which were in use in 1997, our depths reported today do not compare very well with the depths reported by programs of the 90's...

[lmader]

Interesting stuff. Thanks User923005 and Hyatt for your informative replies.

2. DB was different from others of today in terms of the singular extension idea. Nobody does it like Hsu did. Too expensive and too complex. One only has to read his paper to see all the tricks they had to employ (things like the sticky transposition table to make sure that once a move was declared to be "singular" it kept that for a couple of extra plies even if the singular condition was not satisfied, to prevent instability in the search.

they could see some things extremely deeply. today we see much deeper in terms of "plies" reported, but with reductions and forward-pruning, neither of which were in use in 1997, our depths reported today do not compare very well with the depths reported by programs of the 90's...

Regarding that, do we have any visibility into Deep Blue's search depths, both the regular wide search plus the extension depths? Do the logs show this? I'm curious if we can put numbers on this.

[edit]
Also, you mentioned that they would they still not be meaningful for comparison, I guess due to modern reductions and pruning. So does this imply that although Deep Blue's extensions weren't as deep as today's, they were at their depth much wider (thorough)? Just trying to get a better handle on the capabilities and differences.

[hyatt]

Interesting stuff. Thanks User923005 and Hyatt for your informative replies.

2. DB was different from others of today in terms of the singular extension idea. Nobody does it like Hsu did. Too expensive and too complex. One only has to read his paper to see all the tricks they had to employ (things like the sticky transposition table to make sure that once a move was declared to be "singular" it kept that for a couple of extra plies even if the singular condition was not satisfied, to prevent instability in the search.

they could see some things extremely deeply. today we see much deeper in terms of "plies" reported, but with reductions and forward-pruning, neither of which were in use in 1997, our depths reported today do not compare very well with the depths reported by programs of the 90's...

Regarding that, do we have any visibility into Deep Blue's search depths, both the regular wide search plus the extension depths? Do the logs show this? I'm curious if we can put numbers on this.

[edit]
Also, you mentioned that they would they still not be meaningful for comparison, I guess due to modern reductions and pruning. So does this imply that although Deep Blue's extensions weren't as deep as today's, they were at their depth much wider (thorough)? Just trying to get a better handle on the capabilities and differences.

Yes. Supposedly the x(y) numbering means x plies on the SP nodes (done in chess engine software) and y plies done in the ASIC chips, which still did a lot of things, but there was no singular extensions out in the hardware unless my memory is failing (which it might be as this was 15+ years ago.

In any case, 9(6) means 15 plies not counting extensions and the like.

DB's search was definitely "wider" than ours, but it did probe quite deeply due to the SE stuff. They didn't do reductions, or even null-move that we are aware of, although they had null-move in their search for years, but kept it disabled. Hsu hated errors and null-move certainly introduces a few here and there...

[Teargarden]

What made Kasparov lose that match was the conditions of the match! They should of arranged a rest day or 2 between each game! That would of made a huge difference in the result in my view!

[hyatt]

What made Kasparov lose that match was the conditions of the match! They should of arranged a rest day or 2 between each game! That would of made a huge difference in the result in my view!

There were rest days... Not between every game, but every couple of games. As requested by kasparov. Since DB didn't get tired, they didn't care.