Author: Robert Hyatt
Date: 12:16:05 12/25/03
Go up one level in this thread
On December 25, 2003 at 13:47:01, Uri Blass wrote: >On December 25, 2003 at 10:34:00, Robert Hyatt wrote: > >>On December 25, 2003 at 01:12:41, Uri Blass wrote: >> >>>On December 24, 2003 at 23:29:24, Robert Hyatt wrote: >>> >>>>On December 24, 2003 at 22:05:23, Uri Blass wrote: >>>> >>>>>On December 24, 2003 at 20:21:44, Robert Hyatt wrote: >>>>> >>>>>>On December 24, 2003 at 15:29:38, Uri Blass wrote: >>>>>> >>>>>>>On December 24, 2003 at 10:49:31, Robert Hyatt wrote: >>>>>>> >>>>>>>>On December 24, 2003 at 07:55:49, Amir Ban wrote: >>>>>>>> >>>>>>>>>On December 23, 2003 at 23:50:27, Robert Hyatt wrote: >>>>>>>>> >>>>>>>>>>On December 23, 2003 at 23:12:28, Mike S. wrote: >>>>>>>>>> >>>>>>>>>>>On December 23, 2003 at 11:46:52, Robert Hyatt wrote: >>>>>>>>>>> >>>>>>>>>>>>(...) >>>>>>>>>>> >>>>>>>>>>>>In the WCCC event, (1) and (2) are all that is needed. Because (2) had been >>>>>>>>>>>>done dozens of times in previous rounds when programs claimed a draw, using >>>>>>>>>>>>the _same_ GUI, and those draw claims were upheld. You can _not_ then go to >>>>>>>>>>>>a later game in the same event and rule 180 degrees out of phase with your >>>>>>>>>>>>previous ruling, just to justify a stupid mistake that was made. Yet this >>>>>>>>>>>>happened. They accept all draw claims up to this point, then claim that this >>>>>>>>>>>>claim was not made correctly, and then they penalize the _program_ for the >>>>>>>>>>>>operator's mistake, when rules 5 and 6 explicitly spell out the duties of >>>>>>>>>>>>the operator and the remedy when the operator fouls up. >>>>>>>>>>> >>>>>>>>>>>You are aware that the operator/programmer did *not* make a draw claim? He asked >>>>>>>>>>>if it's ok to *continue,* after the GUI's repetition info (and after he had made >>>>>>>>>>>the move). >>>>>>>>>> >>>>>>>>>>Yes. And that is the problem I have been pointing out. The chess program >>>>>>>>>>said "three fold repetition detected." The operator has no choice but to >>>>>>>>>>relay that to the opponent and TD, and end the game. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>I share your opinion that it would better, when operators can, and should, >>>>>>>>>>>remain passive, >>>>>>>>>> >>>>>>>>>>I don't understand the above "when operators can and should ..." By >>>>>>>>>>the rules that is _always_. They _never_ get to make any actual decision >>>>>>>>>>about the game. They only relay what the program says. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>especially when decisions of that type have to be met (claim a >>>>>>>>>>>repetition draw or not), but when currently it's not the exact, clear & written >>>>>>>>>>>rule (?) that operators have to remain completely passive, but when they can >>>>>>>>>>>decide if to claim or if to continue, then I think it was ok to allow the game >>>>>>>>>>>to continue, in that case. - Although - I know - it actually wasn't allowed to >>>>>>>>>>>continue in that sense, but a draw claim was refuted the operator did not want >>>>>>>>>>>to claim :-) but in effect it's the same (more or less). >>>>>>>>>> >>>>>>>>>>I don't see where you get the impression that an operator can decide if to claim >>>>>>>>>>or continue. That is simply _not_ allowed. That is why the TD always announces >>>>>>>>>>that draws and resignations _must_ be passed through the TD first, so that the >>>>>>>>>>operator can't get into the loop and influence the outcome. The TD simply >>>>>>>>>>doesn't allow it. Or at least not until the blunder in Graz he didn't. >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>(It's impossible to put that whole matter into one single sentence :-)) so all >>>>>>>>>>>discussions about it were quite hopeless from the beginning.) >>>>>>>>>>> >>>>>>>>>>>I know that actually there was a misunderstanding about the claim, IOW there was >>>>>>>>>>>none and the TD thought at first Zwanzger wants to claim it. I have already >>>>>>>>>>>critizised that (too), because in the last round of a Championship, in a game >>>>>>>>>>>where one of the leaders participated, and in a situation decisive for the >>>>>>>>>>>title, such misunderstandings are hardly tolerable. These are 3 factors which >>>>>>>>>>>require the highest precision each. - But OTOH, I think the decision itself was >>>>>>>>>>>ok after all. >>>>>>>>>> >>>>>>>>>>How can it be OK when the operator _has_ to do what the program instructs, >>>>>>>>>>and then once he did not, the rule says that the game has to be backed up to >>>>>>>>>>the point where the operator did not follow the program's instruction, and >>>>>>>>>>resumed with the corrected move. It seems perfectly black and white to >>>>>>>>>>me... >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>IMO it would not have been ok to decide like that, when Zwanzger had really >>>>>>>>>>>wanted to claim the draw, just because he had made the move already. That could >>>>>>>>>>>have been tolerated then, and drawn. But in that case, I guess SMK could have >>>>>>>>>>>protested against of course, when FIDE rule 9.2 is in power... At least that's >>>>>>>>>>>my view so far. You know much more about these things. >>>>>>>>>> >>>>>>>>>>FIDE rules don't apply in that context. Because the _computer_ is not making >>>>>>>>>>the moves. IE what if a blind player is playing a game, and tells his proxy >>>>>>>>>>"play Nge2" but the proxy plays "Nce2" instead? The move is wrong, and it >>>>>>>>>>is fixed. Why would anyone even think about penalizing the blind player for >>>>>>>>>>his proxy's mistake? Blind chess rules cover this. The computer tells the >>>>>>>>>>operator what to do. Most operators know how to properly claim a draw, and >>>>>>>>>>they do it correctly since that is the operator's responsibility, to implement >>>>>>>>>>the computer's instructions correctly on the board, including the clock, which >>>>>>>>>>no computer program says "hit the button after making the move" because we >>>>>>>>>>all know that the operator knows that detail. >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>Btw. did you know that Zwanzger, during that same game earlier, had asked the TD >>>>>>>>>>>if he was allowed to resign (when he had a very bad position already), but was >>>>>>>>>>>asked to continue, according to his report at the CSS Forum? >>>>>>>>>> >>>>>>>>>>Yes, and that has happened to me and it is perfectly normal. The operator >>>>>>>>>>can request that the TD allow him to resign when it appears truly hopeless, >>>>>>>>>>but the TD _always_ says "play on until the actual board position shows >>>>>>>>>>that you are dead lost." Many programs _never_ resign, which is perfectly >>>>>>>>>>OK. Rules don't require it. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>http://f23.parsimony.net/forum50826/messages/84889.htm >>>>>>>>>>>(german) >>>>>>>>>>> >>>>>>>>>>>This was a mix of several bad circumstances to the worst moment, so inavoidably >>>>>>>>>>>some sh** happened :-)) >>>>>>>>>>> >>>>>>>>>>>Regards, >>>>>>>>>>>Mike Scheidl >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>>Yes, but it would have been nice had it been fixed, which _could_ have been >>>>>>>>>>accomplished. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>P.S. Under such circumstances, it would not have been perfectly satisfying, when >>>>>>>>>>>Fritz would have been tournament winner later, either. AFAIK Shredder had >>>>>>>>>>>already announced mate (!) in the Jonny game, before the repetion bug occured. >>>>>>>>>> >>>>>>>>>>Would you like some prior examples of this happening? I can cite dozens of >>>>>>>>>>games that were won but lost due to a bug. For example, perhaps the most >>>>>>>>>>famous was the deep thought vs Fritz game in Hong Kong. DT got disconnected >>>>>>>>>>and when things were restarted, it had to move quickly and made a gross blunder >>>>>>>>>>that lost the game. It was recorded as a loss, when it most likely would have >>>>>>>>>>been a simple win had the disconnect not happened. Was that fair? Yes. Was >>>>>>>>>>it the best thing that could have happened for the event? Nope. But it _did_ >>>>>>>>>>follow the rules, and no one complained at all. This is a similar case. >>>>>>>>>> >>>>>>>>> >>>>>>>>>Let's not confuse between bugs and pretexts. >>>>>>>>> >>>>>>>>>DB was trying to avoid a quick loss when it failed, not to win. If it hadn't >>>>>>>>>failed on the c4 move, it may well have failed on the next move. >>>>>>>> >>>>>>>>I don't believe so, that position has been analyzed by many people, using >>>>>>>>GM help and computers. But bad luck happens, and it _does_ change the outcome >>>>>>>>in many cases. >>>>>>> >>>>>>>Both sides had practical chances to win in that position based on comp-comp >>>>>>>games and the point is that nobody claimed that deep blue prototype had a >>>>>>>winning position before c4 so your words( "it most likely would have been a >>>>>>>simple win") are misleading. >>>>>> >>>>>>Not exactly. In almost every "equal" position, they managed to win, because >>>>>>of their speed. >>>>> >>>>>Saying "it most likely would have been a >>>>>simple win" suggest not winning because of being a better player but winning >>>>>because of a winning position. >>>>> >>>> >>>>Think about this. If Crafty gets into a near endgame position that is >>>>pretty even, against something old like gnuchess, it will likely win, >>>>because it simply plays better endings that gnuchess. It doesn't need >>>>a winning position, just an equal position where its search and endgame >>>>knowledge will eventually find a way to win. >>>> >>>>That was what I referred to with Deep Thought in 1995. It was that >>>>much better, that all it needed was a relatively equal position and its >>>>way superior search would turn the game into a win. It did it over and >>>>over and over... >>>> >>>> >>>> >>>>> >>>>>> >>>>>>> >>>>>>>If you assume that deep blue prototype was clearly better than Fritz3 then you >>>>>>>can believe that it could be a win for deep blue prototype without the crash >>>>>>>but I think that it is better not to discuss about the question if deep blue >>>>>>>prototype was significantly better than Fritz3 when there is no way to test it. >>>>>>> >>>>>>>Uri >>>>>> >>>>>> >>>>>>Actually there is a good bit of data about the deep thought machine. For >>>>>>example, the last ACM event in Cape May New Jersey... >>>>>> >>>>>>It was _very_ strong.. >>>>> >>>>>Data about games of previous years against programs is not a proof because >>>>>commercial programs used weaker hardware in previous years and super computers >>>>>often had bugs because of lack of time to test. >>>> >>>>We are talking about 1994. And then Hong Kong in 1995. there was no _huge_ >>>>commercial improvement in that short time-span, neither hardware nor software. >>> >>> >>>The problem is that the number of games in 1994 is not enough to be significant >>>to be sure. >>> >>>It was only one tournament. >> >>You overlook history. A slower DT version played in 1993 and won. A slower >>DT version played in events all the way back to 1987 and won. During the >>period 1987 to 1994, the commercial programs did not make any headway in speed, >>because DT kept getting faster with more processors. And they simply outplayed >>everyone each year they competed, through 1994. I doubt Fritz made some >>miraculous advance in speed from 1994 to 1995. > >I do not say that you are wrong but we cannot prove that you are right(the best >that you probably can prove is a claim like "if we believe the deep blue team >then...") > >You claim that DT got faster not less than the commercial program and we cannot >prove or contradict it when we cannot test different versions of Deep thought >because they are not available. We do know the speeds. In 1986 they were doing over 300K. in 1987 700K. By the end, they were doing something like 14M when they used all of their processors. They also did at least one deep thought re-design, not to mention two during the DB project (DB1 and DB2). Of course we will never be able to prove anything. But having been around them, and having played games against them and saw what their program was searching, and then doing the same against the micros, there was a huge gap between them... > >> >> >>> >>>>DT didn't have a lack of test time. It was a dedicated machine that played >>>>chess all day long. Deep Blue was a different issue as it used an IBM >>>>SP supercomputer as the base platform, and added chess hardware to it. Deep >>>>Thought just ran on a simple machine (sun workstation, later an IBM RS6000 >>>>workstation). >>>> >>>> >>>> >>>> >>>>> >>>>>Comparing based on games against humans is also a problem because humans had the >>>>>disadvantage of not having the machine at home to prepare(Fritz3 with the same >>>>>hardware did the IM norm in one tournament and I read that it did some draws >>>>>against GM's when it had bigger problems against part of the weaker players who >>>>>simply prepared better because they bought Fritz3 when the GM's did not prepare >>>>>and trust their skill that was enough only for getting a draw). >>>> >>>>I'm not talking about games vs humans. I am talking about the annual ACM >>>>event that was held every year through 1994. DT played in them as did >>>>many commercial programs... DT won 'em all. >>> >>>How many games let remmeber that Junior was leading 5-0 and lost the match so a >>>result like 5-0 is not enough evidence without more games. >> >>two programs playing over and over, and they were pretty close to each other >>in strength. DT vs Fritz didn't fit that description. Not comparing 14M nps >>(DT.02 with 16 processors) vs Fritz on a P90 where it _might_ have hit 30K with >>luck, and that is generous. Crafty on a P6/200 used to hit 75K. On a P5/133 >>about 30K. > >Again nps is not a proof and we have no proof when the program is not available. We can be pretty sure their "NPS" was pretty good. They did produce the first _real_ GM rating (over 2600 for 25 consecutive games against GM players, all at 40/2hr or slower). You can't do that with a bad program. > >We even have no proof for the real np number of deep blue prototype when we can >have a proof for the nps of Crafty or every program with source code that is >available. > >Uri Even the NPS with crafty is not stable, due to SMP and other issues. But we can at least compute the max for DB2, and that's a big number...
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.