Author: guy haworth
Date: 07:06:58 09/14/99
Go up one level in this thread
Robert, tfy reply.
I am not (I think) underestimating the difficulty of generating a 6-man etc db,
let alone a 7-man database. Ken Thompson was good enough to report his
difficulties some years ago in ICCA Journal.
Each 'man', all things being equal, multiplies the number of positions by 60.
The problem size is not I think even 'linear' in the number of positions. I
think its memory and disc performance that control the speed of solution.
The six-man databases that might be relevant in this game are:
KQQKQQ - symmetric (halves size) and 2Qs each side (quarters size),
no Ps, factor of 8 less positions, many 'trivial wins' = good news
KQP(g5-7)KQPb(7-2) - Ps but maybe we assume P=Q for any conversion
KQP(g5-7)KQPd(6-2) - ditto
It might also be assumed, though I don't see that this is easy to build in as a
heuristic, that the bK is not going to wander far from its initial position,
assumed to be b1, in about 10 moves time.
Reasons for thinking that a non-zero effort might be possible:
Nalimov's code is available I think on your CRAFTY server
knowledge of even shallow wins in the above 6-man scenarios would be good
KQQKQQ is 'relatively' easy to generate compared to (eg) KRBKBN
according to Stiller, there are wins of depth 44
Wirth/Nievergelt's code (ICCA J v22.2) runs on parallel architectures
there are some big, paralel UNIX/NT machines out there now
the WWW and its community have a habit of surprising us with its responses
the game is proceeding at 1 ply per 24 hours and the next 10m are forced!
Hope this gives you some useful background and reasons why I thought it worth
passing on Peter Marko's request.
Best regards, Guy
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.