Author: Marc van Hal
Date: 07:51:21 01/25/03
Go up one level in this thread
On January 24, 2003 at 23:19:16, Robert Hyatt wrote:
>On January 24, 2003 at 07:24:48, Rolf Tueschen wrote:
>
>>On January 23, 2003 at 21:00:37, Robert Hyatt wrote:
>>
>>>On January 23, 2003 at 10:44:44, Uri Blass wrote:
>>>
>>>>On January 23, 2003 at 10:38:45, Robert Hyatt wrote:
>>>>
>>>>>On January 23, 2003 at 02:18:46, Dux Kazer wrote:
>>>>>
>>>>>>On January 22, 2003 at 21:24:53, Robert Hyatt wrote:
>>>>>>
>>>>>>>On January 22, 2003 at 14:01:09, Rolf Tueschen wrote:
>>>>>>>
>>>>>>>>On January 22, 2003 at 13:02:10, Robert Hyatt wrote:
>>>>>>>>
>>>>>>>>>On January 22, 2003 at 12:27:56, Dux Kazer wrote:
>>>>>>>>>
>>>>>>>>>>On January 22, 2003 at 12:06:37, Matthew Hull wrote:
>>>>>>>>>>
>>>>>>>>>>>On January 22, 2003 at 11:58:05, Christopher A. Morgan wrote:
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>Bob,
>>>>>>>>>>>>
>>>>>>>>>>>>It shows me the abality of GK to negoiate a rule very favorable to him.
>>>>>>>>>>>>It is not at all certain that GK could, over the board, be certain of a
>>>>>>>>>>>>draw in a known draw position as determined with tablebases with, at least all
>>>>>>>>>>>>5 piece endings, and most likely some six piece endings. Now, in those
>>>>>>>>>>>>positions the game will end in a draw, which, in my view, is correct. This
>>>>>>>>>>>>does not address the situation where DJ sees a tablebase draw in its search and,
>>>>>>>>>>>>if it's losing trys to steer the game to that position.
>>>>>>>>>>>>
>>>>>>>>>>>>I like the rule. I do not see any contest between machine and man where
>>>>>>>>>>>>the machine looks up its move in a table, and waits for the human to make
>>>>>>>>>>>>a mistake.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>It is possible the machine could see a tablebase draw which a human would not
>>>>>>>>>>>know how to "solve" and thus lose the drawn position. The human would deserve
>>>>>>>>>>>the loss. This is the point of the man/machine contest.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Oh Yes... but let the machine play without the tablebases and it will lose even
>>>>>>>>>>simple knight vs rook draw for sure, not to say KRP vs KR..
>>>>>>>>>
>>>>>>>>>Not necessarily. Some programs can play krp vs kr pretty well without tables.
>>>>>>>>>I have
>>>>>>>>>special code to handle just this case, for example. I'm sure others do too.
>>>>>>>>>
>>>>>>>>>I'd play _anybody_ KR vs KN with crafty having the KN side... and not expect to
>>>>>>>>>lose.
>>>>>>>>
>>>>>>>>
>>>>>>>>Another challenge to human chess players. Hopefully someone bites. I'd like to
>>>>>>>>see this one too!
>>>>>>>>
>>>>>>>>Marvelous.
>>>>>>>>
>>>>>>>>Rolf Tueschen
>>>>>>>
>>>>>>>this one is too easy. IE I will play kn vs kr without tables. I'll also
>>>>>>>play KQ vs KR without tables playing either side, knowing crafty can win this
>>>>>>>ending _easily_ without tables at all.
>>>>>>>
>>>>>>>I don't think it much of a challenge to avoid losing kr vs kn. Any decent
>>>>>>>search depth will find the simple tactics where the knight is lost.
>>>>>>
>>>>>> I don´t think is that simple.... i know good programmers have special code to
>>>>>>handle that kind of ending but at least the engine has to think for itself and
>>>>>>of course that is time consuming (so human can use that time for himself right?)
>>>>>>and there is always some chance in that case.. i have seen Crafty beaten Fritz
>>>>>>many times in Rook vs Knight (of course without table) and not to say so many
>>>>>>blitz game where human confuse the machine to go for a dead draw KRPP vs KR!.
>>>>>
>>>>>Fritz is a bad example. KR vs KN is only won by zugzwang, when the weaker side
>>>>>makes a mistake. Fritz is very susceptible to zugzwang positions because of the
>>>>>null-move
>>>>>search.
>>>>>
>>>>>I have seen crafty win more than one blitz game KR vs KN without tables. But
>>>>>only blitz
>>>>>games. At longer time controls, it simply isn't winnable unless the opponent
>>>>>makes an outright
>>>>>blunder. There are a "few" deep wins that a table might spot. But against a
>>>>>human, I don't
>>>>>think kr vs kn can be won by the kr side, without the tables, and even with the
>>>>>tables, you can
>>>>>look at the krkn.tbs file to see that the draws outnumber the wins by a huge
>>>>>margin.
>>>>>
>>>>>KQ vs KR is another example that a program can handle simply and almost
>>>>>perfectly with
>>>>>a minimal search.
>>>>
>>>>In both cases you need evaluation that Movei of today does not have.
>>>>
>>>>In KR vs KN you need to know to keep the knight clode to the king and in KQ vs
>>>>KR you need to know that the stronger side needs to reduce the distance between
>>>>the kings.
>>>>
>>>>Uri
>>>
>>>I can only quote what my program can do. IE it can win KQ vs KR against a
>>>program with tables, with just one second per move... The knowledge required
>>>is _really_ modest.
>>
>>Just two boring questions as usual. :)
>>
>>1) Could you explain with words how this is possible now? I mean real champs
>>didn't know how to solve it and you do without tables? Or did you hide the
>>tables in micro format? <g>
>
>Two simple pieces of knowledge:
>
>1. drive the opponent's king to the edge of the board.
>
>2. bring your king closer to his king as well as the queen needs help.
>
>Those two things are all it needs. In fact, Amir Ban mentioned that this was
>easy to win in 1997, and I didn't believe it. I tried it, and was amazed that
>Crafty without tables could win the KQ side vs crafty with tables, with no
>problems at all. Not optimally, but pretty close...
>
>IE tables might say mate in 30, while crafty might take 35-40 moves total. All
>you need is a small bit of knowledge, with a decently deep search.
>
>>
>>2) Because you said "just 1 minute", let me ask you if you believe in the myth
>>that by each generation (each year) we win a 2x hardware speed and therefore
>>after a couple of years we have (allegedly) the strange effect that we could
>>play the earlier tournament time mode in say 0,6 seconds for the whole (sic!)
>>game. There is a debate in Germany and I also wrote aboute it in
>>
>
>I play game in 1 second tests all the time. Its a good "stress test" of
>the parallel search and everything else... So yes, you could either speed
>the game up as hardware gets faster, or stay at the same time limit and take
>advantage of the greater depth.
>
>
>
>>http://hometown.aol.de/rolftueschen/SmallTalk.html
>>
>>Could you give a few factors such a maths above perhaps had overseen/forgotten?
>>I want to quote you. Thanks.
>>
>>Rolf Tueschen
now how about king pawn Knight versus King Rook
or king pawn Bishop versus Rook
or king 2 or 3 pawns versus rook
Because this all depends much of the place of the pieces
But now serious in some cases even with table bases programs don't find the only
way to win certain endgame positions.
Ok if you show them a couple of time they do
It plays like it doesn't mather which move order is adopted but this is very
criticial in endgames.
Marc
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.