Author: martin fierz
Date: 14:27:51 04/11/02
Go up one level in this thread
On April 11, 2002 at 17:10:57, Alvaro Jose Povoa Cardoso wrote: >>hi alvaro, >> >>have you written your own program by now or did you adapt mine? if you are doing >>the second, then the answer to your question is "it's irrelevant" - and probably >>the answer is the same if you wrote your own program... my generator took 5 >>weeks on a XP1600+ with 1GB ram to build the 4-4 database (and anything >>smaller). once you have this, you will never need to compute it again... another >>point is that in spanish checkers, you should be much faster building the db, >>because AFAIK kings sweep, and you have lots more captures which take you in >>smaller databases much faster than in english checkers, i.e. the number of >>passes per db you have to do should be much smaller. >> >>in the meantime, i have compressed my database, and am working on the access >>code. believe me: this is the part you have to do right - not the db computation >>itself. >> >>aloha >> martin > >Hi Martin, >nice to hear from you :) > >Unfortunately I didn't even started. I'm anxious to read the code you sent me. I >have very litle time, since I work all day and get home very tired. But I'm very >interested in solving this EGTB problem. My interest in 32bit reversing is >because it will be used in the program search engine for 'white to move' >positions. I agree it is not a great issue but if I can do it a little faster >then I'll do it. Yes you are right about Spanish/Portuguese checkers greater >number of captures. if you haven't started, i'll send you a newer version - i have added lots of comments in the meantime, i have written compression code and access code - you would only have to change the move generator in the db generator. the access code works well as long as everything is in memory, but if it's not in memory, it is VERY slow. i will try working on that... the reverse operation is totally negligible compared to the decompression of a block in memory, which is in turn totally negligible compared to the disk access if you need to load a block. >Martin, I red Jonathan Schaeffer's paper and I have doubts about resolving the >non-capture positions (I think I didn't understood all of the algorithm). My >(surely stupid) question is: When generating the tablebases we do have to make >an alphabeta search for these non-capture positions don't we? (contrary to the >capture positions in that we get the results from lesser piece databases). no alphabeta is needed. during generation, you have exact scores for every position. which means that a 1-ply search is always enough. if your 1-ply search doesn't find out what the result of the position is, you just move on, and hope to resolve it later. eventually, this will resolve all positions except the draws. >Also, in the engine I was planning to put all the 4 piece databases in memory >and the others I read from disk. Do you think it is sensible? no. the english 4-piece db needs only 200KB. since my compression code "floats" values of capture positions, you will get a smaller value for this for spanish checkers. my 6-piece db is 39MB, yours should again be clearly smaller, which means you could easily put the whole 6-piece db in memory. my generator should build and compress that db in half a day or less on a good machine, if your move generator is as fast as mine :-) >Also, do you use 2 bits per entry in your databases or do you use a byte with >distance to win/loss? the uncompressed version uses 2 bits per entry, there is no distance to win. aloha martin
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.