Author: Oliver Roese
Date: 04:24:04 12/14/00
Go up one level in this thread
On December 13, 2000 at 12:56:20, Robert Hyatt wrote: >On December 13, 2000 at 12:36:42, walter irvin wrote: > >>On December 13, 2000 at 11:35:28, Robert Hyatt wrote: >> >>>On December 13, 2000 at 06:06:26, Lin Harper wrote: >>> >>>>On December 12, 2000 at 22:12:04, Robert Hyatt wrote: >>>> >>>>>On December 12, 2000 at 18:15:14, Mike S. wrote: >>>>> >>>>>>On December 12, 2000 at 16:19:27, Robert Hyatt wrote: >>>>>> >>>>>>>(...) >>>>>>> >>>>>>>The real problem is that GMs that are not in the top 100 give programs fits on >>>>>>>ICC all the time. I won't mention names, but it is common. Because they tend >>>>>>>to play the opponent, which is perfectly normal. I don't think a GM would care >>>>>>>_which_ computer he has to play, but he would certainly want to know that he >>>>>>>is playing a computer (I think computers are more similar than most would give >>>>>>>them credit for being). >>>>>> >>>> >>>> What's Roman Dzhindi's handle on ICC? >>> >>> >>>Roman plays anonymously on ICC, and I always respect such a request from >>>GM players, so that I don't reveal their handles. You might pick some of >>>the top engines, do a "history" on them, and see if you find a common >>>opponent that wins more games than usual. :) >>> >>> >>> >>> >>>>>>I'd be interested, what your opinion is from watching these ICC GM games: What >>>>>>is the most important, or most often successfully used anti-computer strategy? >>>>>>Is it >>>>>> >>>>>>a) avoiding tactics and using superior positional knowledge >>>>>>b) following long-term ideas or plans, which the computer fails to understand >>>>>>c) preparing for a king attack slowly, and the computer defends too late >>>>>>d) looking for a transition into a better endgame, or >>>>>>e) something else (?) >>>>>> >>>>>>Thanks, >>>>>>M.Scheidl >>>>> >>>>> >>>>>The idea is to first block the position. Normally you would first block the >>>>>center, then as the computer tries something on the queenside, you take every >>>>>opportunity to block things there, or, on occasion, let the queenside sorty >>>>>draw the computer's queen offside chasing a pawn. It then can leave itself >>>>>wide open for a slowly developing kingside attack. The rule of thumb is _first_ >>>>>position your pieces, and _then_ push the pawns. Because the program will >>>>>see what is going on once the pawns start moving. If you do it right, it will >>>>>be too late. >>>>> >>>>>Another strategy is to simply block the position completely, keeping yourself >>>>>one pawn break to play at the right time. Generally programs will not >>>>>understand the position and will be out of position when the break comes. >>>>> >>>>>A good person to watch is Roman Dzhindi... He is very good at this sort of >>>>>playing, and drives programs into the ground if they don't try _very_ hard to >>>>>prevent the blocked position early... >> >> >>all this anti-computer stategy is great ,but you as a programmer and the one >>with prob the most experience vs humans ,have any ideas or suggestions on a >>ANTI-HUMAN stategy that would help computers turn the tables on humans .i mean >>if there are positions where computers dont play well , then there must also be >>positions where computers are much better ??? maybe a good match between opening >>book and eval ?????????? > > >It is not easy. A human GM is something to behold. They know more about >book transpositions that anyone would imagine. Which means that no matter >what you do, they are most likely going to steer the opening into something >they like and understand. And that is a problem for computers. > >I have lots of code to help Crafty understand blocked positions. _before_ they >get too blocked to fix. But it is still possible to trick it through opening >transpositions so that the position is blocked before it has a chance to use >its evaluation rules to avoid this. This is on my list to look at somewhere in >the future. But it is a huge problem now. I don't believe it is possible to >create an opening book that is "GM-proof" so that you always get a reasonable >position. Without the program taking an active role in selecting book moves >as they are played. > >And then there is the problem of trying to avoid all blocked positions. This >is _not_ what you really want to do all the time. If your position is bad, >then blocking things up is probably good most of the time. Yet the current >Crafty implementation still struggles to open things up, which is backward. >I plan to make this a "drawish algorithm" at some point. IE if you look at >my eval right now, I have a variable that says "white can't win" or "black >can't win" (ie in a KRN vs KRPP with white having the KRN) white can't win >that position. Black probably can't but he has _all_ the winning chances. >I plan to do this for the blocked position evaluation as well. IE at present, >the blocked position stuff is somewhat asymmetric, with crafty always hating to >see things blocked. What I want to do is that when the eval is bad (from >crafty's perspective) then it will "like" blocked positions, while if the eval >is good (again, from crafty's perspective) then it will "hate" blocked >positions. This makes it fully symmetric where the better side wants to open >things up while the worse side tries to avoid this. Of course you dont want to do this against humans at _any_ time, i think. From my own experience in short time controls i can "tell", that an open position can compensate the computer a pawn, at least againtst me. Even in games between strong humans it is sometimes to, so this rule is not so ridicolous how its sound at a first glance. The weaker side has then so much possibilities to create threads, that the stronger side cannot make progress. It would be interesting to see if this is really so, but i dont have the time to check that out... Oliver > >But it is very messy, along the same lines as the messiness in trying to >handle king safety, which is also a very difficult thing to evaluate. I like >the way the current code handles attempts to block the position, except for >those cases where it really should be trying to block the position, or keep it >blocked, rather than trying to blast things open.
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.