Author: Eugene Nalimov
Date: 11:04:02 04/02/04
Go up one level in this thread
Hi Johan, Glad to hear from you. First, I did not feel any friction. Sorry if I left that impression. It's hard for me to talk with people who I just met, especially if it happens the next day I (and 2 kids, one of them is 2 years old) switched day and night. Ok? Second, I never wrote (here or anywhere else) that my TBs are better. I just replied when Marc wrote that yours are better :-). They were designed for different purposes. Mine were designed with probing in the search in mind -- and yes, there are some engine authors who believe in probes during search. Thus I had to compromise on compression. Plus, I wanted to be able to generate w/d/l from them at some point, so I deliberately decided to keep explicit "illegal value"; for w/d/l it can be replaced by w/d/l score depending on the TB. Your tables were designed for probing at root, so decompression speed -- and block size -- were not an issue. You wrote "Decompression time is tiny compared to random disk access", and I agree. That is why I am using small blocks -- main benefit is that you have to read less data from the disk, not decompression speed itself. Bob and I run lot of experiments before we came to 8K blocks. I initially pushed for 64k :-) I just made the experiment -- I compressed krpkr using 32k blocks and slightly modified DATACOMP (it is free to replace "illegal value" by anything it wants if it thinks it will improve compression). Size went down from ~150Mb to ~136Mb. Still larger than yours :-(, but those extra 6% allows to always probe exactly one file. Yes, generation speed is the issue with 6 men... I can say only that it was not the issue for 5 men; on 2GHz P4 I can generate all 5-men TBs in ~1 week. Slower than you, but still reasonable. Instead of speeding up the code I spent time working on something else, e.g. on verifier (all TBs I distribute passed full verification, and I would be very surprised if they contains any bugs). So, code was written 7 years ago, and was intended only for 5 men. Later Guy and others pushed me to go for 6 men, but now I have one more kid, and wife with full-time job, so I cannot dramatically rewrite it. Let's agree that both your and mine TBs are "cool". Thanks, Eugene PS. I agree that my TB code is in the Microsoft style: not the best possible one, but good enough, solid, makes what it was intended to do, and became a de-facto standard :-) On April 02, 2004 at 02:13:53, Johan de Koning wrote: >On April 01, 2004 at 22:30:27, Eugene Nalimov wrote: > >>I see. So in FEG your have krpkr wtm, krpkr btm, krkrp wtm, and krkrp btm. Than >>yes, you can figure value without the search, at a cost of (probable) extra TB >>probe. Extra probe is unavoidable when the score is a draw. > >As Uri pointed out, one can easily avoid these extra probes inside >an alpha-beta search. > >But as Theron pointed out some years ago, one should avoid *any* >probe inside a search. > >>So your are paying that price, and slower access due to 4x larger block size, to >>achieve ~30% smaller TBs. Reasonable tradeoff, but I would not call it "better" >>:-) > >Decompression time is tiny compared to random disk access, and it is >getting tinyer all the time. Hence when we're talking about 20% smaller >(rather then 30% !) it's not a trade-off but simply a small advantage. > >When it comes to "better", there is the simple fact that FEG generates >the data [BLEEP]ingly fast. On any machine. Without the need to update >whenever some Pawn is added to whatever side. > >Please accept that fact and don't play stupid (or should I say don't >play MicroSoft?). Though my social intelligence is close to retarded, >I can't help sensing friction eversince we met (Maastricht 2002). >I'm trying to ignore it, and letting it be your problem. But as you >can see, sometimes I fail to ignore it. Let's just say Nalimov TBs >are cool and FEG is cool, OK? > >>BTW you can achieve better compression in .emd files by replacing all "broken" >>scores by the most common non-broken score in the TB. I always was curious how >>much it will save, but never made the experiment... > >Do the experiment and be surpised. Surprised by the fact it doesn't >save much. Surprised by the fact that, given a suitable symbol size, >statistical compression works much better than intuition. Well, we >knew that already. But still it is scary. :-) > >... Johan
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.