Author: Eugene Nalimov
Date: 18:30:23 04/01/04
Go up one level in this thread
On April 01, 2004 at 21:15:05, Marc Bourzutschky wrote: >On April 01, 2004 at 20:36:32, Eugene Nalimov wrote: > >>On April 01, 2004 at 20:03:20, Marc Bourzutschky wrote: >> >>>On April 01, 2004 at 17:59:38, Eugene Nalimov wrote: >>> >>>>On April 01, 2004 at 15:16:34, Marc Bourzutschky wrote: >>>> >>>>>The Chessmaster format is indeed better >>>> >>>>What does it mean "better"? :-) >>>> >>>>It stores less information, thus compresses better. >>>> >>> >>>No, it stores the same information, just in two different files. Those files >>>together are still somewhat smaller than the Kadatch compressed ones... >> >>AFAIK it doesn't stores non-wins for side to move. Is it so? That alone should >>result in the better compression. >> > >It stores complete information, just distributed differently. For example, the >equivalent of the Nalimov krpkr in FEG is the set of krpkr and krkrp. Each >stores only wins for the side to move, but between the two you get the exact >same win/loss/draw information. krpkr and krkrp in FEG format togther occupy a >little under 127Mb, while the krpkr.nb?.emd files take 150Mb. The complete >5-man set in FEG is about 5.6Gb. Ok, let's assume that position in krpkr is loss for white to move. Where in FEG that information is stored? Not in krpkr, because it is not win for side to move. Not in krkrp because other side is to move. What I don't understand? Thanks, Eugene >>And as was pointed by Gian-Carlo Pascutto FEN format does not allow you to >>search in the tree -- i.e. it allows slower decompression. For example, you can >>achieve ~10% better compression with Kadatch algorithm just increasing block >>size from 8k to 16k. For larger block sizes you can achieve even better >>compression using slightly modified algorithm (modifications are useless with >>small block sizes). >> > >Yes, the block sizes may be an important factor. FEG uses 32k. How much of the >compression advantage would disappear with smaller block sizes only Johan de >Koning knows... > >-Marc > >>But I believe main reason for better compression is just less information in the >>files. >> >>Thanks, >>Eugene >> >>>-Marc >>> >>>>Thanks, >>>>Eugene >>>> >>>>>but no interface other than through >>>>>Chessmaster is available. Besides, the Nalimov format has become a quasi >>>>>industry standard. Since the contents of the two tablebases is the same, the >>>>>main advantage of the Chessmaster is faster generation with less RAM, and >>>>>somewhat smaller compressed file sizes. If there were a tool to translate >>>>>Chessmaster format to Nalimov format we would already have all the 6-man >>>>>tablebases by now. >>>>> >>>>>On April 01, 2004 at 14:18:16, Jason Kent wrote: >>>>> >>>>>>On April 01, 2004 at 14:07:22, Kurt Utzinger wrote: >>>>>> >>>>>>>On April 01, 2004 at 13:56:25, Jason Kent wrote: >>>>>>> >>>>>>>>I just read this in the FEG.txt that i got off the chessmaster website. >>>>>>>> >>>>>>>>XVI. WHY THE FEG FORMAT? ================================================ >>>>>>>> >>>>>>>>Perhaps, after reading all of this, you are wondering why Chessmaster >>>>>>>>9000 does not use either of the more commonly used EGDB formats, namely >>>>>>>>those created by Eugene Nalimov or Ken Thompson (both of which bear the >>>>>>>>names of their creators). There are many reasons for this: >>>>>>>> >>>>>>>>1. FEG data is about 20% smaller. Additionally, half-sets can be used if >>>>>>>> hard drive space is an issue, making a "full useable" file set that is >>>>>>>> almost 1/3 the size of the complete Nalimov file set. >>>>>>>>2. FEG generation is much faster and doesn't need a huge amount of free >>>>>>>> RAM to create a set of files. >>>>>>>>3. FEG can do any 6-man files on a 32-bit platform. >>>>>>>>4. The Thompson format is not a complete set (especially pawns on both >>>>>>>> sides are lacking). >>>>>>>>5. The Thompson format stores DTC (Distance to Conversion) values, >>>>>>>> meaning that it stores the number of moves to either mate OR to a >>>>>>>> capture/promotion, and will play whichever move has the smallest >>>>>>>> winning value. This can result in silly moves (a capture that leads to >>>>>>>> a mate in eight moves instead of a non-capture that leads to mate in >>>>>>>> three moves). >>>>>>>>6. Since Chessmaster 9000 is a mass market product, the majority of its >>>>>>>> users are not aware of these other formats and how to get them. Also >>>>>>>> for the ease of development it is easier not to be dependent on >>>>>>>> technical support for data that was created using tools that were not >>>>>>>> developed by Ubi Soft. >>>>>>> >>>>>>> Hi Jason >>>>>>> Maybe you have asked the wrong question: "Why does Chessmaster 9000 >>>>>>> not support the egtb format that all other engines do?". >>>>>>> Kurt >>>>>> >>>>>>The reason I ask is because the egtb format sounds like its a little better. I >>>>>>kinda wish cm9k used nalimov so it would be more compatible.
This page took 0.01 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.