Author: Marc Bourzutschky
Date: 13:12:21 04/02/04
Go up one level in this thread
On April 02, 2004 at 14:04:02, Eugene Nalimov wrote: >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 :-). Sorry Eugene, I should have expressed myself more diplomatically. Both Tbs (and the generating code that goes with it) are great, but for somewhat different reasons. Eugene clearly had to do a lot of retrofitting to an old program and it is to his credit that it still works reasonably well. People have ported his code to different platforms and have adapted it for all sorts of purposes, such as generating different metrics, chess variants, etc. FEG is unsurpassed at speedily cranking out 6-man TBs on very cheap hardware. I apologize that my somewhat inconsiderate remark seems to have sparked a rather confrontational thread! -Marc 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.