Author: Vincent Diepeveen
Date: 07:32:03 02/03/05
Go up one level in this thread
On February 02, 2005 at 21:33:44, Robert Hyatt wrote: >On February 02, 2005 at 17:18:07, Vincent Diepeveen wrote: > >>On February 02, 2005 at 15:17:15, Robert Hyatt wrote: >> >>>On February 02, 2005 at 13:22:54, Anthony Cozzie wrote: >>> >>>>On February 02, 2005 at 11:46:48, Robert Hyatt wrote: >>>> >>>>>On February 02, 2005 at 01:33:29, Tony Werten wrote: >>>>> >>>>>>On February 01, 2005 at 21:55:56, Peter Skinner wrote: >>>>>> >>>>>>>On February 01, 2005 at 21:39:40, Anthony Cozzie wrote: >>>>>>> >>>>>>>>Is there any chance of some 6-man tables becoming available before CCT? My wish >>>>>>>>list is actually pretty small: >>>>>>>> >>>>>>>>KRPKRP <--- Only white available, and totals 3.41gb of space. >>>>>>>>KRPPKR >>>>>>>>KQPKQP >>>>>>>>KQPPKQ >>>>>>>>KRKPPP <--- That one would be absolutely HUGE!! >>>>>> >>>>>>Not really. The 3 pawns give a big reduction. The total number of entries for >>>>>>each color is below 2GB. (1806*62*((48!/(45!*3!)))) >>>>>> >>>>>>The biggest problem might be that because of the amount of (under)promotions you >>>>>>will need all other KRKZZZ tables to generate this one. >>>>>> >>>>>>Tony >>>>> >>>>>The other issue is compression. KRKPPP probably has +lots+ of wins, which means >>>>>few 0 scores and resulting poor compression. >>>> >>>>Isn't this a good argument for W/L/D tables? What I would _really_ like to have >>>>is a full set of 6-man W/L/D tables, plus DTM tables for the complicated endings >>>>that I just posted. Once the full 6-man set is generated, it should be pretty >>>>simple to just run through and convert each to a W/L/D. Of course, Eugene seems >>>>pretty busy these days :) >>>> >>>>anthony >>> >>> >>>Make 'em. :) >>> >>>If you think about it, it is not hard. 6 loops, one for each piece's possible >>>squares. Probe the table, if the score is > 0 it is a win, = 0 is a draw, <0 is >>>a loss. The resulting files will _still_ be big. The 8 bit tables will shrink >>>by about a factor of 5. The 16 bit tables will shrink by a factor of 10. You >>>still end up with a _bunch_ of gigabytes. Say 100gb per TB. >> >>That's already a far different statement than a while ago. > >Not from me it isn't. I don't use W/L/D tables. I don't intend to use them. >But if someone wants to, the above savings are certainly possible. > >> >>Entire uncompressed size of diep's 6 men is 1 TB. > >No comment. Never released or seen by another human being. Eugene's are used >by everybody else, including yourself apparently since you mentioned having all This is another claim from someone from the 80s. What you want me to ship. My source code or so? >of the on some "supercomputer". Do you use your own or not? If not, why not? The supercomputer affair was in 2002/2003. It's 2005 now in case you forgot. I use the nalimov's to test against fritz basically. Verification of the diep indexing scheme has been done already for all 6 men. Did it with a double test. Wonder whether Nalimov did that with his. Took 6 months for diep a position2index + index2position, old one didn't have en passant. What i'm verifying now is egtb generator format for 6 and a few 7 men. Most likely i'll be generating more 7 men than Nalimov will. I guess Nalimov within a few years will either quit or will have to rewrite his generator + format. Those mothers are big. Just about to order a RAID5 card as a matter of fact. >> >>Now you are saying: "say a 100gb" ==> 100 gigabit = 14GB. >> >>Vincent > >I didn't say any such thing. I said for 16 bit files (and not all the 6 piece >files in Eugene's format require 16 bits) a 10:1 reduction would be possible. >For the 8 bit tables, more like 5:1. I'm not considering compression and doubt >they will compress much better... > >So I guess I totally miss the point of your post... You should go in politics Bob, only there i heard bigger nonsense.
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.