Author: Uri Blass
Date: 11:05:17 02/20/03
Go up one level in this thread
On February 20, 2003 at 13:51:37, Filip Tvrzsky wrote:
>On February 20, 2003 at 12:49:39, Uri Blass wrote:
>
>>
>>I guess that you mean
>>#define gen_dat_i_mpromote (gen_dat[i].m & (63 << 16))
>>
>>I guess that the laternative that I tried
>>
>>#define to(x) (((x)>>8)&255) was also bad
>>and better was
>>#define to(x) (((x)&255<<8)
>>
>>I guess that in that case I need to change some more code
>>
>>For example
>>
>>I have today some cases when I have
>>switch(m.bits)
>>case 1:
>>case 17:
>>...
>>
>>in that case I need to say case 1<<24 and in order not to have an ugly code
>>I need to have more constants for 2^24,2^24*17,...
>>
>>I can use
>>enum
>>{
>> bits1=16777216
>> bits17=
>>...
>>}
>>
>>Uri
>
>#define to(x) (((x)>>8)&255) is definitely worse than #define to(x)
>(((x)&255<<8) because in the first case the shifting is done in run-time and in
>the second during compilation. Note also that the result of both macros is
>different. For the same reason is "move & (some_bit << 24)" better than
>"bits(move) & some_bit".
> I agree that it is very usefull to define some more macros (or an anonymous
>enumeration) like:
>#define PROMOTION (0x8 << 24)
>#define CASTLING (0x4 << 24)
>#define CAPTURE (0x2 << 24)
>and so on and avoid those "magical" numbers which make any change of
>implementation to be a nightmare.
>Better way to use these bitflags than switch statement is IMHO this:
> if (move & CAPTURE) do_something;
>[else] if (move & PROMOTION) do_something_else;
>I think also that (move & PROMOTION) is quite clear expression, it isn't?
>I have to repeat that the point is here to read the move value from memory and
>then maximally exploit all information which it contains: this means also
>somewhat concentrate the making of decisions in your code and minimalize the
>branching in it. I vote also for splitting your move generator in more parts
>(maybe normal moves, qsearch ... it depends on your search algorithm of course)
>for the same reason.
>Filip
The last point may be relevant only for the function that make moves.
I already did my program faster by splitting the move generator that is the
part that generates the moves and not make them but I have no seperate
makemove functions for different moves.
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.