Author: Gerd Isenberg
Date: 12:38:59 10/28/02
Go up one level in this thread
On October 28, 2002 at 15:35:02, Uri Blass wrote: >On October 28, 2002 at 15:13:23, Heiner Marxen wrote: > >>On October 28, 2002 at 14:06:54, Uri Blass wrote: >> >>>On October 28, 2002 at 13:17:56, Uri Blass wrote: >>> >>><snipped> >>>>My question is if array is the fastest way to do other things like finding if a >>>>rook move is pseudo legal. >>>> >>>>rook move is pseudo legal if the file is the same file or the rank is the same >>>>rank(I can ignore the case when both are the same because this case never happen >>>>and I never expect hash move or killer move when both are the same even in case >>>>of hash collision) >>> >>>After thinking more about the problem it seems that my 2 dimentional array is >>>not the same as checking if the move is pseudo legal because when I get the >>>direction between the squares I get more information than knowing if the move is >>>pseudo legal(the exact direction between the squares(left,right,up,down) >>>and this information is used later. >>> >>>The main question if there is a fast way to calculate the function >>>direction(x,y) when >>>1)direction(x,y)=0 for up direction >>>2)direction(x,y)=1 for down direction >>>3)direction(x,y)=2 for left direction >>>4)direction(x,y)=3 for right direction >>> >>>only a function that is faster than 64*64 array is productive. >>> >>>I am interested in the same question for bishop when direction(x,y) can get >>>4,5,6,7. >>> >>>Uri >> >>Hello Uri, >> >>As you may have seen in the Chest sources, such a direction computation >>can be done with a considerably smaller table, if you start off with >>0x88 coordinate values. The table is indexed with the difference of the >>two 0x88 coordinates, and has size apx 16*16 = 256 entries. >> >>I think, that the biggest problem with such tables is not so much their >>own size, but the cache footprint they leave. That can severely slow down >>the rest of the program. >> >>Whether some computational effort (function/macro) is faster than a table >>lookup, heavily depends on the hardware, e.g. how large is the penalty for >>conditional branches (when decisions are involved), and how smart is >>the compiler to make use of special HW features to avoid conditional code >>for simple conditional constructs (that is possible sometimes). >> >>I will ponder a bit about your exact direction function. > >If you are interested in my exact direction function >then I can tell you that it is the following function. > >Today I remember it in an array. >squares in the board are numbers 0-63 > >a1=0 >b1=1... >h1=7 >a2=8... >a8=56... >h8=63 >direction is array 64*64 of int > >direction[i][i]=-9; >direction[i][j]=-2 if i and j are knight direction >direction[i][j]=-1 if i and j are in no direction and not identical. >direction[i][j]=0 if j>i and they are on the same file (I define dup=0) >direction[i][j]=1 if i>j and they are on the same file (I define ddown=1) >direction[i][j]=2 if i>j and they are on the same rank (I define dleft=2) >direction[i][j]=3 if j>i and they are on the same rank (I define dright=3) > >I have in my code > >#define dleftup 4 >#define drightdown 5 >#define drightup 6 >#define dleftdown 7 > >I think that the definition of direction is clear based on this defintion and >based on the previous explanations. > >Note that I read that it may be better to use enum to define constants(the >practice of programming page 20) but I got that book too late and I did not care >to change the #define to enum. > >I read that it is a dangerous way to program but I did not read examples for >the risks. > >Uri
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.