Author: Johan de Koning
Date: 17:16:18 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? It was more you writing (several times) that FEG data contains less infomation that left the impression. Let's call it a misunderstanding then, and I think we're fine. >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. Yes, IMHO "believe" is the right word here. :-) But I'd better not touched on that because it is an different (and endless) discussion. >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. If I understand this, you store brokens as a value different from draws. In that case your data does actually contains more information than FEG's. :-) Though you are aware that brokens can be reassigned cheaply on the fly whenever needed, aren't you? >Your tables were designed for probing at root, so decompression speed -- and >block size -- were not an issue. Actually it was desgined for production speed. At the time, no data with more than 1 Pawn was available and the first goal was to build KPPKP ASAP. >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 don't think disk block size is an issue with 21st century disks and file systems (it could influence the soft cache though). So you might want to try to push that 64k again some day. >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. That's more gain then I expected. But then again, I did'nt expect the original 150 MB to contain 2 values for draws and brokens. >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 :-) I'll grant you that. But FEG's data is on 100,000 CDs. :-) Thanks for replying, Johan >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.