Author: Robert Hyatt
Date: 18:52:58 11/27/98
Go up one level in this thread
On November 27, 1998 at 21:49:23, Robert Hyatt wrote: >On November 27, 1998 at 20:15:19, Amir Ban wrote: > >>> >>>--------------------------------------------------------------------- >>>There are intermediate PV reports in what I see, with a >>>timestamp attached, and there is no "end-of-iteration" PV. The form and >>>timing of PV reports looks like any other program's (except for that >>>axb5, which comes out of nowhere, after the search stopped). I do wish >>>you would refrain from making value judgements or speculating on my >>>motives before getting the facts straight. If you then decide not to >>>believe me, that's a different matter. >>>----------------------------------------------------------------------- >>> >> >>This comes from me. Why you think this strengthens your point I've no idea. It >>just says what I've said here. > >Because it replays what you wouldn't admit... DB liked Qb6, until the last >iteration. It displayed Qb6 and apparently thought it was bad because the >score had dropped. It thought a while, then out of the clear blue said it >was going to play axb5. > >The output from crafty said it liked move 1 for every iteration until it >ran out of time. It then thought significantly longer, and out of the clear >blue announced it was playing a *different* move. That was the point of >contention here. More in a minute. > >> >>Something else: this short passage also reminds me that mud throwing has always >>been one of your favorite tactics in this debate. > > >Here's my advice. You want to throw a punch at me, make sure it is a killer, >because I certainly punch back. Here is my query from 2 posts back in this >thread: > >----------------------------------------------------------------------------- > >I don't understand... we are on the position where it liked Qb6 until >it changed at the last minute to axb5? or are we on the position with >Qb6 vs Be4? If the former, then what is reversed, since Crafty liked one >move for the entire (albiet only 16 second) search but it changed its mind >and produced a new best move when the search terminated. So I don't follow >"the order of events is reversed..." > >------------------------------------------------------------------------------ > >Nothing personal, nothing insulting, no nothing. Then look at *your* post >in response to this. And then decide who is being a wise-ass and throwing >"mud". > > >> >>Good lord, it does seem that you really don't understand the difference between >>BEFORE and AFTER, so I will try to explain the difference slowly, but you'll >>have to really concentrate now. >> >>Bob gives an example: >> >>>I don't understand the "unexplained circumstances". Here's some output from >>>a game crafty played today: >>> >>> 9 1.34 -1.32 28. ... a6 29. h4 Be6 30. h5 Kd6 31. >>> h6 gxh6 32. f5 Ne5+ 33. Kg3 Bxa2 34. >>> Bxh6 >>> 9 16.30 -1.28 28. ... Bc8 29. b4 Ba6 30. a4 Bc4 31. >>> b5 <HT> >>> time=16.30 cpu=394% mat=-3 n=5055833 fh=88% nps=310173 >>> >> >>Now here we have a simple example of BEFORE, yes ? The line starting Bc8 comes >>BEFORE the line announcing the end of the search. Actually the search end right >>after it. We can easily explain what happened: A line for Bc8 was found >>sometimes DURING the search (that's what the search is for, children). The >>search stopped AFTER the line was found, and in this case, probably BECAUSE the >>line was found. >> >>Now in this nice printout from this nice big company, we see an example of >>AFTER. The order of the events is REVERSED, and in fact we see three messages in >>this order: First there is a message saying it's now time to stop the search. >>Second there's a message saying we are now going to "reconstruct the main line". >>Third, we have a message showing a line with axb5 (which was never seen before >>this). >> >>Now, assuming we understood the distinction between BEFORE and AFTER, we do not >>really know to explain what happened, because the cause-and-effect element is >>gone. First, we don't know why the search stopped. No event preceded it, and it >>was not time to stop it according to the timer. Second, and more important, we >>don't know where the line axb5 came from. It was not found during the search (we >>know that, children, because Deep Blue like Crafty neatly announces every new >>line when it is found), but it was found AFTER the search, when the machine had >>stopped searching. >> >> > >first, a question: are you *that* inexperienced in programming in a multi- >threaded environment? If so, then perhaps your ignorance in the above attempt >at interpreting something could be understood. If you *have* done multithreaded >programs (ie even Belle used one thread for console I/O, one for the search >engine, as did Cray Blitz and every other unix-based program I know of except >Crafty [because crafty also was written to run under DOS and there are no >multithreading facilities there]) then you should realize that the above is >not odd at all. And your "interpretation" that my node summary marks the end >of the search is right for Crafty, wrong for Cray Blitz. In cray blitz, the >console "task" manages time. And it tells the search engine "time is up." It >immediately dumps the statistics it has gathered, and would occasionally run >into the case where the engine was just updating the PV at the same time as the >statistics were getting dumped, and whomever does the fflush(stdout) *first* >gets their output first. Cray Blitz did this... and no one ever thought to >interpret the data as you seem to want to do. This happened often enough that >in blitz games I turned the stats off because when they pop out before the move, >I'd have to wait (at 1200 baud) longer than I wanted. > >This is threading 101, lecture mode, and it is common. Multiple threads have >multiple buffers, and the "order" doesn't mean a lot. I'd be happy to post some >cray blitz output from the 1994 ACM event to show you *exactly* what I mean. > >You are attaching too much importance to "order" of output... variations >"should" come out in order since I know they don't do parallel searches at the >root. But as far as statistics interspersed in the variations, that doesn't >mean a thing, except to those that want to assume dark motives. > > > >>> >>>It would be nearly impossible to prove they didn't cheat. It would be just as >>>difficult to prove they did. >>> >> >>Rationalizations, rationalizations. What I told happened exactly as I told it. >>Go and find it. >> >>Amir > >There's nothing to find. When you (one day) try some threaded stuff, you will >finally understand that "boy, what I said back then was really stupid, because >I am now seeing the same stuff from *my* program." You might try to fix it, or >you might do as Hsu did (and we did in CB) and just let it be. But it does't >mean something wrong went on. > >We call that "jumping to conclusions" where I come from. Particular (I hope Netscape goes under soon, I am tired of a browser that crashes in the middle of a post). To finish that last line: Particularly when there are other perfectly reasonable explanations for the output as you see it. Just because *you* can't understant it doesn't mean *we* can't. That little bit of "timing" that bugs you was not even something I noticed because I was used to it with Cray Blitz. Is that the *only* thing that bugged you? In that case it would have been nice if they had sent you several game logs. Them you probably would have seen that multiple times and decided "hmmm... looks ugly, but consistent with other odd search output". The "conspiracy theory" doesn't hold water. Never did, never will. One day you'll understand just how bad this looks...
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.