Author: Vincent Diepeveen
Date: 09:59:55 09/01/05
Go up one level in this thread
On August 30, 2005 at 18:44:05, Dieter Buerssner wrote: >On August 29, 2005 at 14:01:31, Vincent Diepeveen wrote: > >>On August 29, 2005 at 10:45:38, Duncan Roberts wrote: >> >>>On August 29, 2005 at 03:29:12, Marc Bourzutschky wrote: >>> >>>>During the past 6 months Yakov Konoval and I have collaborated on efficient >>>>algorithms to exactly solve 7-man endgames. Yakov has come up with a program >>>>that contains every trick in the book, and then some. Many of the ideas are >>>>refinements of those used by Johan de Koning in his path breaking FEG program. >>>> >>>>Our hardware is extremely basic, about US $3,000 worth of equipment: a single >>>>3.6 GHZ PIV, with 4 GB RAM, two 250 GB IDE hard disks, running Windows XP. >>>> >>>>To put Yakov's programming skills in perspective, his program solves the >>>>infamous 6-man krnknn endgame in just over one hour on that hardware. >>> >>>Great achievement. well done. >>> >>> >>>how long would a dtm program have taken to solve the 6-man krnknn endgame on >>>your machine. ? >> >>DTM requires much more than just a little bit overhead. >> >>Additional i feel there is no need for DTM. >> >>From the huge size that Marc shows for their DTZ egtb's, compressed still >>a formidable 160GB for just a single EGTB, it is obvious IMHO that >>win/draw/loss is just so so superior. >> >>of course in case of marc's egtbs there is only a 'win/no win' distinction >>possible. They don't have a 'loss' component. >> >>That would reduce their EGTBs in win/no win format dramatical further! >> >>Yet at generation time, creating WDL is nearly the same effort like DTZ. >>DTM is really a lot effort more, and if you ask me, just a bit overdone for >>the big EGTBs. > >With a slight variation of the DTZ algorithm, you will be able to construct TBs >that respect the 50 moves rule. This is obviously not possible, when you only >use WDL. Marc did not tell details about the algorithm they used, yet. I guess >RAM requirements at creation time would be the same. But perhaps RAM >requirements is a non issue with the method used by them. For pawnless a couple of hundreds of MB's will do. Pawnless 7 men very easy to calculate rapidly. With pawns and en passant is a lot harder to solve technical, because the tricks that can speedup generation bigtime get more complex. The biggest goal is of course having EGTBs like KRPP KRP Actually 50 move rule at generation time is very easy and takes care you are quite a tad faster. I'm using bitmaps with win in N. Of course at initialisation time i initialize a few more bitmaps, like the 'exchange can give draw bitmap' which must run with one of the 2 passes (there is a loss in n pass and a win in n pass). That bitmap you simply sequential stream during generation time. i/o of it is not neglectible but pretty little, however if you transform the generator to something that can quickly stream then the i/o gets massive again because the indexation you use is a lot more rude and therefore massive overhead is there because of using 64 possibilities for most pieces. If you're generating mate in n in that case for like 2 pieces at same square, you're just streaming without calculating, so streamspeed from i/o to RAM and ram latency is a big issue. The RAM size itself is a smaller issue, but it can be used excellently perhaps to already stream into RAM meanwhile already busy calculating at other section. Vincent >Regards, >Dieter
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.