Author: Dan Newman
Date: 02:35:47 08/28/98
Go up one level in this thread
On August 27, 1998 at 23:20:09, Larry Coon wrote:
>On August 22, 1998 at 14:30:15, Dan Newman wrote:
>
>>Hi,
>> Here's something I dug up from my files: SJE's readme.tb file.
>>Hope this helps.
>
>I've now had a chance to digest it completely, and it answered
>almost all my questions -- thanks again.
>
>However, I do have a couple of questions.
>
>SJE's doc listed specs for only a few of the existing
>tablebases. I think I can infer the pattern in the
>remaining files, but I want to double check:
>
>1. Is it safe to assume that "qsf" (queenside)and "tri"
> (a1-d1-d4 triangle) indexing are never used in the
> same tablebase file?
Yes, that's my understanding too. When there are only pieces on
the board there are more symmetries to play around with than when
there are pawns, so we can use the "tri" indexing for one of the
pieces. Since pawns are highly directional you lose a lot of the
symmetry and must go to "qsf" indexing--which gives less than
a third of the "compression" that "tri" gives.
>
>2. Is the order of array indexes always the reverse
> order of the piece order in the tablebase name?
> (eg: in KQRKR would they be bR, bK, wR, wQ, wK?)
I don't know for sure, but I've always assumed that would be
the case. (I think I've probably made the same inferences you
have--the readme.tb doc is the only thing I've had to go by).
>
>3. Is the last black piece in the tablebase name
> always the one with the "tri" or "qsf" index,
> unless there's a pawn, in which case it's the
> pawn?
I think so. I don't know what happens when there
are multiple pawns on one side though...I suppose it
would be the pawn with the "slowest" index that gets
the "qsf" indexing.
>
>4. Is it true that if the last piece is a pawn the
> first index is always "qsf", otherwise it is "tri"?
Yes and no. If there is a pawn anywhere, you can't use "tri"
indexing because that will make pawns go sideways (so to speak)
when remapping is done. So, whenever there are pawns present
there is exactly one "qsf" index, otherwise there is exactly one
"tri" index. Ex's:
KPK (bK wP wK) has the signature "all qsf all".
KRPKR (br bK wP wR wK) has the sig "all all qsf all all".
(Well, at least I've assumed this would be the pattern.)
KPKP: "qsf all all all".
KQRKR: "tri all all all all".
>
>So to continue with my example, for KQRKR it would be
>the C array:
> signed char KQRKR[10][64][64][64][64]
>with the subscripts and scanning patterns: bR = "tri",
>bK = "all", wR = "all", wQ = "all" and wK = "all",
>respectively. Yes?
Yes.
>
>I have more questions about the following:
>
>>Note that all the tablebases are constructed with White as the side with more
>>material (e.g., better winning chances). If Black is the side with better
>>material, then the colors are reversed and, if any pawns are present, the
>>piece positions have to be reflected across the X axis prior to indexing.
>
>I'm unclear as to the order in which things are done here.
>Let's say the following position appears:
> 8/8/8/5kp1/8/6K1/8/8 w
>
>According to this I reverse the colors and reflect across the
>X axis:
> 8/8/6k1/8/5KP1/8/8/8 b
>
>and will now use the tablebase KPK.tbb. But since the indexing
>in this tablebase is "all", "tri", "all", I -now- have to
(should be "all qsf all" for KPK)
>reflect about the Y axis, right? So this gives me:
> 8/8/1k6/8/1KP5/8/8/8 b
I get 8/8/1k6/8/1PK5/8/8/8 b (but I see by your indices below
that you do too.)
>
>and I can now look up my value in KPK.tbb[41][13][26]. Is this
>the correct process?
>
Yes. (This always twists my brain into a pretzel--esp. the "tri"
indices.)
>Thanks again,
>
>Larry Coon
You're welcome.
-Dan.
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.