Author: Dann Corbit
Date: 16:32:33 04/05/04
Go up one level in this thread
On April 04, 2004 at 13:49:00, Uri Blass wrote: >On April 04, 2004 at 12:48:00, Vincent Diepeveen wrote: > >>On April 02, 2004 at 23:17:58, Robert Hyatt wrote: >> >>DIEP raw compressed format : >> >>28-03-2004 02:15 218.108 kqqqkp_w.dtb.emd >>28-03-2004 02:14 134.072 kqqqkp_b.dtb.emd >> >>Same tables in nalimov format: >>-rw-r--r-- 1 500 500 650212520 Sep 11 2003 kqqqkp.nbb.emd >>-rw-r--r-- 1 500 500 115294214 Sep 11 2003 kqqqkp.nbw.emd >> >>Factor 1000 compression or so here. > > >I am not impressed. > >KqqqKp is almost always a win for the stronger side. > >I suspect that the only cases when it does not happen can happen only when there >is a stalemate or when there is a pawn in the 7th and the drawing move is a >promotion. Which begs the question, if the excess information is excess baggage, then why are the Nalimov tables so large. >You simply do not need these tablebases because you probably can by static >evaluation solve everything and in the rare cases when there is a pawn in the >7th that can promote you can look in tables with no pawns. Perhaps this idea can create a great compression for special tablebase files like this one. If we store ONLY moves that do not lead to a win for the stronger side, then perhaps the whole thing can be stored in 10,000 entries or so. For really dominant tablebase files (lopsided 95% or more) it might be a good idea.
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.