Author: Robert Hyatt
Date: 20:30:03 11/27/98
Go up one level in this thread
On November 27, 1998 at 21:52:58, Robert Hyatt wrote: >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... \\ I should also have added one more plausible explanation for the PV *after* the "so called end of search output"... I don't do this any longer, but older versions of crafty would, when a search ended, try to "extend" the PV by probing the hash table. They may well do this when a move like axb5 fails high but doesn't have a chance to resolve a score. After the search exits, you could try probing the hash table to recover pieces of the PV although there will likely be some bizarre moves in it. I quit doing this about 2 years ago and chose to "extend" the PV as soon as this happens, rather than "waiting" for a bit... to avoid overwriting some of the hash data. *any* of the explanations I've offered sounds better than "cheating". But then I put a little thought into what might cause such output in a legitimate way, rather than jumping to conclusions about misbehavior on the part of the DB team. Why do we keep "going there"??
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.