Author: Rolf Tueschen
Date: 06:03:20 07/11/02
Go up one level in this thread
On July 10, 2002 at 11:04:29, Robert Hyatt wrote: >Here is what happened. > >During the early Summer, Bert Gower and I were playing nightly games using >Cray Blitz running on a vax vs several different micros. We were running >about 100 nodes per second and doing 5 ply searches. We were doing this to >get ready for the 1985 ACM computer chess tournament in Denver, and we knew >I was moving to Birmingham in August to start work on my Ph.D. > >We noticed that we were generally tactically stronger than any of the micros >we were playing against, and in tactical situations, we won easily. But on >occasion, we would create a "hole" in our pawn structure that would hurt us >in the endgame where the opponent could infiltrate off-side and cause trouble >since we were both doing pretty shallow searches. > >To fix these holes, I added two lines of code into the pawn evaluation loop >in Cray Blitz and further testing showed that we had "closed the door" on the >pawn hole problem and we lost no more games due to that problem. Just to make this clear. This historical anecdote is a masterpiece and should be told to every chess programmer. At the same time your story shows the main weakness of the past decades of computerchess programming. Until this very day! I just wrote a new article on SCW (Thorsten Czub Forum) about the game between JUNIOR and SJENG in Maastricht, a terrible mess for chess, only possible with the modern books and cookings, because no machine could have any idea about the coming endgame. But this endgame, for this specific variation after the sac of the quality on e4 with the best continuation on both sides, is simply won for White. See the game in the databases with a real master as White. To play this anyhow - is for me personally, excuse me, in non-crime vocabulary, "confidence tricksing" on chess. "Tricksing" also on the spectators world-wide who might think that they attend master chess, which is not at all the case. A computer wouldn't even dare to play the Marshall Gambit without exclamation marks in its books! You know, SJENG can play just to the exchange on e4 but is unable to see the difference between the bad Qd7 and the better Qh6. That is what I was talking about. There is simply no consistancy in the play of the machines with today's book-hypocrisy of course. The question from an interdisciplinary interest's standpoint is, why you at the time being did _not_ reflect about possibilities to find programming "tricks" closely related to chess itself. Why you did think that by a comparably more "stupid" or "magic" approach you could better win against comparably less strong machines? In other terms. Why didn't you reflect about real solutions, coming from chess, to find the right moves, also better later in the endgame? Or this. Would you have changed your code this way also against equally strong or stronger (just joking) machines? Or was it all a consequence of your own "strength" in chess? In just another variation. Why didn't you try to find technical mirrors of real chess, chess of its best possibilities? Of course your solution was something from chess but not reaally sound. BTW what do you mean with testing? Against other machines or human players? [Just added: why did you never feel unconfortable with programming tricks, said to be successful in 98% _only_. I mean what with the 2% with deterministical certainty? For me such a procedure is _wrong_. A good human player will take advantage of such "holes" in your system. Tell me please if it's a typical learning by doing because your opponents were machines and not human players...] > >When we got to denver we played not very well and lost 2 of 4 games, with >the new HiTech machine winning the tournament. I was neck-deep in my first >year of Ph.D. classes and just thought "seems that several have 'caught up' >with us" and let it go at that. > >The next year, at the WCCC tournament in Cologne, we won easily in the first >round, but lost in the second to a program that really had no business beating >us (we were running on an 8 cpu Cray I believe). The same question as above. Did you concentrate in your code on chess or just mastering your machine? ;-) >After losing in round 2, we >started looking to see what was wrong. It was playing _very_ passively with >its pawns and its score would climb as the opponent pushed his pawns. On a >"whim" I commented out the two lines of code dealing with pawn holes. Suddenly >it started finding the moves it used to find. In games where it played horribly >passively, it suddenly started to play aggressively as it used to. > >We left those two lines of code out, and we easily won the next three rounds, >including beating HiTech in the final round in a convincing way. A way so >convincing that Berliner accused of of cheating because "no computer would >play some of those moves." > >A change that worked _great_ at 100 nodes per second and five ply searches, >turned out to be terrible at 9-10 plies. After a lot of study, it turned out >that the pawn hole code was covering a hole that other eval terms were handling >with the deeper searches. Which basically made holes twice as bad at 10 plies >as they were at 5 plies. Removing two lines completely changed the character >of the program, and it also _clearly_ shows that an eval for a shallow search >can be quite different than what is needed for a significantly deeper search. > Just to explain Vincent's difficulties! You have forseen it before the tournament in Maastricht. Give us more details about the dependencies between hardware and resulting qualitative differences. > >What if you only do very shallow searches. So shallow that you can't under- >stand some simple positional idea. You add eval code to handle that. Then >you search far deeper on different hardware and you both see the consequence >of the positional idea thru search, _and_ you see it thru eval. A "double >dose". If you tune the positional term down so that it doesn't double-deal you >on fast hardware, it is ineffective on slow hardware. If you turn it up so that >you don't make the positional mistake on slow hardware, you might find yourself >paranoid about the problem on fast hardware since you see twice the penalty. >That is what happened to us. Could it be avoided? No idea. But it _clearly_ >can happen. It _did_ happen for one well-known program... Mine... The Hsu team of IBM did avoid it by introducing GM Benjamin into the testings. IMO he had to check nonsense and contradictions of the play in relation to the books. > > >If you play on ICC long enough, you learn that you have to "turn up your king >safety" to survive against IM/GM players in bullet/blitz games. Otherwise they >attack you before you know you are being attacked. You then discover that this >makes you very passive in long time controls. And you have to turn it back down >or else you play so passively you get squeezed to death. Happens to most >everyone that plays there. You get the right "setting" for say 1 0 bullet, >then at game/60 minutes you become way too passive. Or vice-versa... I hope that you finally agree that Kasparov was far from trying such subtile methods in 1997 against DEEP BLUE II. More he wasn't even able to try. Simply because he didn't know the machine's performance at the time being. I know that you commented already, but this thread showed us that most people still have no understanding for the real connections between hardware and software. For some FRITZ is already as strong as DBII. Rolf Tueschen
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.