Author: Robert Hyatt
Date: 06:47:09 03/16/01
Go up one level in this thread
On March 16, 2001 at 01:41:43, Carlos del Cacho wrote: >On March 15, 2001 at 19:00:31, Dann Corbit wrote: > >>On March 15, 2001 at 18:52:16, Thomas Mayer wrote: >> >>>Hi Dann, >>> >>>>This one is (of course) the real toughie: >>>[D]2b5/1r6/2kBp1p1/p2pP1P1/2pP4/1pP3K1/1R3P2/8 b - - acd 24; acn -1238874665; >>>acs 86401; bm Rb4; ce 279; id "WAC.230"; pv Rh7 Rb1 a4 Ba3 Rh5 f4 Kd7 Kg2 Rh4 >>>Rf1 Kc6 Kg3 Rh7 Kg2 Rg7 Rb1 Bb7 Rb2 Rg8 Kg3 Kd7 Kf3 Rh8 Ke3; >>> >>>> I have an idea how to break WAC 230 with chess engines. Have an algorithm >>>> that detects wall formation (impenetrable formation of any type). Then, give > a centipawn evaluation of zero until the wall is breached. >>>> Has anyone tried this? It seems it could be done simply enough. You would >>>> only have to go a few plies forward with this wall detection thingy for it to >>>> be effective. >>> >>>I think Steffen Jakob yes tried something in experimental versions of his Hossa. >>>- There is more information about this on his homepage... >>>http://www.jakob.at/steffen/hossa.html - But he do not use this in practical >>>play for hossa, I think there are to many position where it does not help, where >>>it is maybe a problem... I think blocked positions will be a problem in chess >>>programs for the next few years... - At the moment I am testing this with Quark, >>>I think it will find it after 25 plys or so... but that could take maybe a week >>>or so, no idea at the moment... After 19 minutes it has completed ply 17 for the >>>PV and is still at a4. I have some long discussions with my beta-tester Leo >>>Dijksman about this position - when you move on here some moves in the correct >>>PV Quark will see quite fast what will happen... but for practical play it is >>>absolutely to deep... >>>Anyone tried with Shredder 5 ? >> >>I think: >> It is easy to see a blocked position. It should be easy enough to program. >>Consider (for instance) blocked position detection of exactly 3 plies (so that >>we also have enough time to prevent in simple cases) or even blocked position >>detection of only the current ply. For the current ply, it will only be a >>microsecond to see it. For three plies, maybe 1/10 second at worst. So once we >>have seen a blocked position, we can use that to modify our eval. I think with >>that simple modification, this problem (in particular) will be solved very >>quickly. >> >>Not sure about others, though. >>;-) > >I see a problem with that open file at f. How do you tell the computer well no >one can get in and the king in g4 will live there for the rest of his life >without trouble.... and also forget about the pawns in a,b because they can get >easily blocked. This is way to hard for computers and trying to implement a >general rule for this would rise quite a bunch of exceptions where you will get >killed. This is my personal opinion, of course. Blocked pawns are not so hard to find. Crafty has some code that does this extremely accurately, to try to prevent these from happening. It builds a big bitmap of squares that pawns can move to, which takes into account how many pawns attack and defend each square. This way it doesn't have to have two pawns rammed together to know they are blocked. It is still hard to figure out what to do, of course. Right now I simply penalize the score when there are lots of pawns and few or no lever possibilities...
This page took 0.02 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.