Author: Robert Hyatt
Date: 15:21:52 01/20/00
Go up one level in this thread
On January 20, 2000 at 09:15:20, Amir Ban wrote: >On January 20, 2000 at 08:22:03, Robert Hyatt wrote: > >>On January 20, 2000 at 03:22:56, Jeremiah Penery wrote: >> >>>On January 20, 2000 at 02:18:51, Ed Schröder wrote: >>> >>>>On January 19, 2000 at 18:55:42, Dann Corbit wrote: >>>> >>>>>On January 19, 2000 at 18:34:52, blass uri wrote: >>>>>[snip] >>>>>>The question is if the move of deeper blue was the right move. >>>>>>It is not clear that 36.axb5 was the right move. >>>> >>>>>So the argument against 36.axb5 was that it is not such a good move? >>>>>Every program has bugs. There are a very large number of tunable parameters >>>>>with the deep blue machine. Perhaps one (or many) of them was not optimal. >>>> >>>>You misunderstand. It's the DB main-line for 36.axb5 what made Kasparov >>>>suspicious. In this main-line DB sacrificed 3 pawns for no direct win >>>>but for a dangerous looking king attack, all very human-like. Kasparov >>>>could not believe his eyes (he still can't) and started the accusation >>>>human intervertion took place as he could not believe a computer was >>>>able to produce such a (super) main-line. >>>> >>>>So this whole issue is NOT about the move 36.axb5 but about the asthonising >>>>main-line DB produced. >>> >>>I think it depends completely on the evaluation, specifically the king-safety >>>evaluation. From looking at the log files, it seems that DB evaluated >>>king-safety much differently than most (all?) other computers. [I could be >>>wrong here - I'm basing this by the fact that the last move of many of the PVs >>>it gives were strange looking moves that seem to lose material to open lines on >>>one of the kings, like in this PV from move 37 of game 2: Be4 Rcb8 g3 Qd8 Ra6 >>>Rxa6 Rxa6 Bc7 Rxf6.] It may also have been asymmetrical, valuing its own >>>king-safety higher than the opponent's. >>>Certain modified Crafties I've produced will play axb5. Some of them will play >>>it right away, and some will switch from Qb6 after a deep search. One in >>>particular I remember liked Qb6 for a long time (15 ply, IIRC), then produced a >>>line _very_ similar to the one DB produced for that move. It switched to axb5 >>>before the next ply, just as DB did. >>> >>>I think I'll go back and analyze again the line DB gave for move 36. Qb6, to see >>>if white could get improve on it and get better than a draw. >>> >>>Jeremiah >> >> >>The PV of DB is totally unreliable. Remember this: >> >>When they did what they called an 11 ply search, that was 11 plies in software, >>plus another 4 plies in hardware, plus captures. And also recall that the >>hardware only returned a score/best move... there was no facility to try to >>store the PV in hardware (Belle had the same problem). Which means that the >>only way to construct a PV is to probe the hash table. You would think that >>this is totally accurate, but it isn't. In Crafty, when I get ready to do a >>ponder search, I try three things: >> >>1. If I have a PV, and it contains 2 or more moves, I try the second move in >>the PV. >> >>2. If 1 fails, I do a hash probe and if I hit, _and_ the entry has a move (all >>entries don't have a best move, ie positions that failed low) I try that move >>to ponder. >> >>3. I do a search for the opponent (short time limit) if 1 and 2 fail. >> >>I see, fairly frequently, where I fail high at the last minute, which means that >>I have no PV. So (1) above fails. (2) gets a hit and I ponder some move where >>the score is +7.xx, even though the real score is only +1. The opponent makes >>a more reasonable move, and the score drops back to +1 or so. If I produced a >>PV with that move in it, it would look ridiculous. >> >>Since DB's hardware can't back up a PV from the hardware, the hash table is >>the _only_ place you can pick this up. And the deeper you go, the farther you >>get from reality. The end of the PVs can be utter nonsense... > >There were indeed some PV's in moves 36 & 37 that looked like typos. The Rxf6 >line could be explained in this way. There was another which looked weird in a >different way and I think needed a different theory. > >Now that we have all logs, the thing to check is whether there are other PV's >that look like this. If it turned out that only moves 36 & 37 had such nonsense, >it would be remarkable. > >Amir I will look of course. However, I have seen this "oddball ponder move" problem _way_ more than I would have _ever_ speculated was possible. One good test would to _only_ ponder the hash table move found after making the program's best choice. It will usually be the PV move, until fail highs or fail lows at the root occur. Then it seems that it can be nonsense, for reasons I don't always understand. IE hanging a queen, etc... I once wanted to dump the PV code and just use hashing. But for debugging it seems annoying to depend on something that might have garbage moves in it. And I don't hash in the q-search so I would never see what is getting traded away on the end of the PV, which would further hurt debugging... Ken Thompson had this nonsense in Belle, and typically did 2 plies of search in software on the PDP-11, and the rest in hardware, which means he almost _always_ had a two move PV with no clue about what was happening deep in the tree excepting for a score... Not my cup of tea for testing/evaluating changes, unfortunately...
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.