Computer Judgment
chris whittington
>
> As an example of how chess programs lack "judgment" the British
> mathematician Roger Penrose gives the position below with White to move.
>
> .......kr
> ......b.p
> ...p...pP
> rpPp.pP.
> pP.PpP..
> P...P...
> ..K......
> .........
>
> Penrose states that Deep Throat (White) took the rook and lost the game
> whereas even a human beginner would have secured the draw by simply
> moving his king around behind his solid wall of pawns.
>
> Question: Does anyone know of a chess program that would have the
> judgment to refuse the rook capture and thus secure the draw?
>
> Question: This is for players of Go-- is this an example of the
> lack of overall sight of the board that makes master-level Go programs
> so much harder to write than master-level chess programs?
>
There is no program trhat I know of that could solve this position, but,
having said that, it would not be very difficult to write a knowledge
algorithm which could solve such a position:
down on material, but no way for opponent to penetrate - probably take
two days programming time, given a program with a 'complete' data structure.
But the question arises - would it be worth it ?
Such a situation is contrived and unlikely to arise in real play, the
time taken in calculating the necessary knowledge each node would be better
spent elsewhere.
I'm not trying to argue against knowledge, in fact, my program lives
pretty much by knowldge and not search - but anyone will be able to
generate contrived positions to show how 'stupid' program algorithms
are. We need knowledge, but not pointless knowledge.
chris whittington
Walter Ravenek
> mathematician Roger Penrose gives the position below with White to move.
> ......kr
> .....b.p
> ..p...pP
> rpPp.pP.
> pP.PpP..
> P...P...
> .K......
> ........
> Question: Does anyone know of a chess program that would have the
> judgment to refuse the rook capture and thus secure the draw?
My chess program Arthur has code to handle this sort of position.
As Chris Whittington remarked, it is not very hard to program:
there must be a continous chain of pawns and the stronger side
must not be able to capture one of the pawns.
However, is it worth the effort? I found it a nice challenge, but
it has little practical value, so I decided to deactivate the code
to save me some evaluation time.
chris whittington
>
> > As an example of how chess programs lack "judgment" the British
> > mathematician Roger Penrose gives the position below with White to move.
>
> it have infinite time to think about it. Practically (in a tournament
> game) there would be no way it would see the draw (on my mac, mind you).
> But, after about an hour and twenty minutes, it finally moved the king to
> c2, giving the score for the move as +0.01 (ie-A draw is going to happen).
> It got to a depth of 17. I run on a 33Mhz, hence the long thinking time,
> but regardless, it did eventually see the draw as being better.
>
> RDuckie256
Thinking about this position (and similar ones), I think I might want to change
my mind.
Really this position falls into the class of 'fortress', and programming
a special case 'fortress' evaluator may well be worth the evaluation time,
not for this position, but for many others. Anyone got any ideas ?
In general the position referred to is interesting, not in itself, but
because it throws up the knowledge-search dichotomy. Sure, search will
solve this problem, like it can solve all problems if given enough
time - BUT, is it chess ? Surely the knowledge approach has to be the
way forward, and, with faster processors, more space for code, what
excuse do programmers have for not writing human-like evaluation functions ?
chris whittington
Peter Gillgasch
|> Thinking about this position (and similar ones), I think I might want to change
|> my mind.
|> Really this position falls into the class of 'fortress', and programming
|> a special case 'fortress' evaluator may well be worth the evaluation time,
|> not for this position, but for many others. Anyone got any ideas ?
Of course detecting such a fortress draw when all the pawns are on the board
is pretty easy. When having bitboards it is a shift, a "and" and a compare.
When you have something in your eval() that checks for blocked pawns then
it may be even worthwhile to implements, since the only additional thing
you need is the compare instruction...
If there are some pawns missing it is a entirely different story!
|> In general the position referred to is interesting, not in itself, but
|> because it throws up the knowledge-search dichotomy. Sure, search will
|> solve this problem, like it can solve all problems if given enough
|> time - BUT, is it chess ? Surely the knowledge approach has to be the
|> way forward, and, with faster processors, more space for code, what
|> excuse do programmers have for not writing human-like evaluation functions ?
Oh no. Please spare us the ritual "knowledge vs. search discussion" (^8
-- Peter
------------------------------------------------------------
Peter W. Gillgasch
Klosterweg 28/I-113 email gil...@ira.uka.de
76131 Karlsruhe/Germany Phone ++49/(0)721/6904255
Dan Thies
> I'm not trying to argue against knowledge, in fact, my program lives
> pretty much by knowldge and not search - but anyone will be able to
> generate contrived positions to show how 'stupid' program algorithms
> are. We need knowledge, but not pointless knowledge.
It's also possible for computers to generate positions to show how
"stupid" humans are, such as KBBKN endings, KQKR endings, etc.
It's much more interesting to find positions from over-the-board play
which computer's can't solve.
Dan
Robert Hyatt
-->chris whittington (chr...@cpsoft.demon.co.uk) wrote:
-->
-->> I'm not trying to argue against knowledge, in fact, my program lives
-->> pretty much by knowldge and not search - but anyone will be able to
-->> generate contrived positions to show how 'stupid' program algorithms
-->> are. We need knowledge, but not pointless knowledge.
-->
-->It's also possible for computers to generate positions to show how
-->"stupid" humans are, such as KBBKN endings, KQKR endings, etc.
-->
-->It's much more interesting to find positions from over-the-board play
-->which computer's can't solve.
-->
-->Dan
This reminds me of the famous "artificial stupidity" paper presented in London
at the Advances in Computer Chess IV conference. I was having a discussion with
the author of this paper, the subject being the Turing Test. He was claiming that
no current program could come close, and I challenged him on that. He produced a
position, I gave it to cray blitz, and after about 2 seconds, it announced a mate
in 13. Correct, he said, and also he claimed QED. His point was that *no* human
cound find that mate in 13 in 2 seconds, in fact, it took GM's several minutes to
find it. Seems that the program was "too good" in that case. Obviously this is
fixable, by simply introducing a random delay that is somehow proportional to the
depth of the mate found so you don't find one too quick, and you don't take too long
on an obvious mate. Even more obvious, why would I (or anyone else), after working
so long and hard to make our programs fast, then artificially slow 'em back down to
the speed of "mere flesh and blood?" I aspire *upward* and not *downward*... :)
--
Robert Hyatt Computer and Information Sciences
hy...@cis.uab.edu University of Alabama at Birmingham
(205) 934-2213 115A Campbell Hall, UAB Station
(205) 934-5473 FAX Birmingham, AL 35294-1170