Author: Sune Fischer
Date: 11:01:51 10/08/03
Go up one level in this thread
On October 08, 2003 at 13:21:53, Russell Reagan wrote: >On October 08, 2003 at 09:18:51, Sune Fischer wrote: > >>There is just one thing about the geometrical relations I don't understand. >> >>Suppose you do >>dir = sq1-sq2+128 (in 0x88) >> >>then dir is going to be some multiply of the direction and not (usually) the >>step size needed for the board scan in the direction of dir. > >dir in this case isn't very useful by itself. You only use it in a table lookup. Yes matter of habit, should have been without the +128 obviously :) >In the table, you could basically add the same entries for multiples (ex. the >entry for an offset of 8 would contain the same entry for an offset of 16, 24, >32, and so on). Can this be done without a table in 0x88? I mean you can do the same lookup into a 64x64 table. >Or you could make use of the actual offset between two squares. >Maybe that could be useful in a king and pawn endgame where you have a pawn on >the other side of the board which your king can't save. I think pawn races can be done with no table lookup at all, in both 8x8 and 16x8 and others. It's pretty simple geometry really :) >>So if one needs a table lookup in any cas, what's the great advantage over the >>smaller 64 sized board? > >If I understand correctly, I think you're talking about the method TSCP uses? >This uses an extra table lookup (two lookups) to get the next square. You could >use a lookup table that was [64][64], but that is both bigger (4KB at best) and >slower (2D array vs. 1D array) than a 256 element array. Yes in this case you get a smaller table, that is probably true, but I need a bigger reason than saving 4 kb on one table to choose this structure, other tables are likely to grow from the square having a larger range. >Also, I don't think the main use of the sq1-sq2+128 lookup is to find the step >size for scanning. The main benefit is to save a lot of work. For instance, if >you are trying to determine if a piece on a square can attack another square, >you can do a lookup for the offset of those squares, and if it's not possible >for sq1 to attack sq2, then you're done. Actually this off-set information can be stored too in a 64x64 array. :) > If not, you can scan the board for >blockers. Same thing for determining if the last move could have left the king >in check, and all kinds of things that are dependent upon square relationships. I do all of that, the only difference would be using a 64x64 table. It would be great if there was some way to determan relations without a table lookup, but I think if one is going to use a table the possibilities are practicly endless no matter what structure one uses. >I would not use the sq1-sq2+128 table lookup for move generation, for instance. >I would just have an array of offsets probably. See Gerbil move generator for an >example. Yes right, either that or unroll it. Doing loops of fixed sizes seems like a bit of a waste because of the unnecessary branches at the ends, unless the compiler can figure that out on its own? It's like C/C++ needs a few keywords here to specify unrolling of simple code repetitions. :) -S.
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.