Author: Robert Hyatt
Date: 08:23:25 09/14/99
Go up one level in this thread
On September 14, 1999 at 10:06:58, guy haworth wrote: >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 > Eugene will probably shoot me, but he is actually looking into making a few 6 piece files available. Pawnless files are just over 1 gig each. So doing 3 vs 3 is possible, but they aren't going to be built quickly nor on small- memory machines. But KQQ vs KQQ is doable, and is almost certainly not going to have mates > 127, which would break the current store/probe algorithms we are using. But others that are more esoteric (still pawnless, as pawn endings are a bit much at present) like KQN vs KBB might be very deep wins that require more than 8 bits to hold the result... I told him that if he built them, I could put 'em on my ftp machine... But they are going to be _big_ files... >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 Yes... but Eugene makes certain assumptions in his generator to make it efficiently produce these things. And one such assumption is _big_ memory boxes. IE he recommended 512mb for generating 5 piece endings with one or more pawns. This is likely either going to be bigger for 6 man files, or else it is going to fry the disk with paging I/O. Eugene can give estimates if he is reading this... > > 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 Note that Stiller's code ran on a Cray. The main reason was _huge_ memory as his program requires that to produce the files, and at the time he did the 6 piece files, nothing but Cray's had that much memory (16-32 gigabyte machines exist today at Cray).
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.