Author: Don Dailey
Date: 09:41:22 12/29/98
Go up one level in this thread
On December 29, 1998 at 04:58:40, Roberto Waldteufel wrote:
>
>On December 29, 1998 at 02:29:41, Jeff Anderson wrote:
>
>>I've begun working on a chess program, and am in the very early stages. I have
>>come up with an idea, or a shortcut, but I fear it may have some negative
>>consequences. In my numerical representation of the chess board, instead of
>>having for example 1 for a pawn, 2 for a knight, 3 for a bishop 4 for rook, 5
>>for queen, 6 for king, -1 for black pawn and so on, could I not make the
>>numerical representation of the piece its value? For example instead of 2 for a
>>knight, the knight could be 300, and a black knight could be -300. The white
>>bishop might be 320 and the black king -5000 and so on. Would this not kill two
>>birds with one stone, and save me the trouble, of assigning the piece values
>>another place? It would make the evaluation much easier, because all I would
>>have to do is add up the total value of each element in the board array (not
>>counting positional considerations).
>>Jeff
>
>Yes you can do this, and it works (I used something very similar in my earliest
>attempts at chess programming), but as you suspect there are cons as well as
>pros. Any time you need to step through all piece types (eg for correct ordering
>of captures), it is easy to code "for piece=1 to 6.....etc", but not so easy
>when your pieces have different values. Also, do you not intend to use
>piece-square tables to give a value for each type of piece for each side for
>each square? I found piece-square tables very useful, but then it no longer
>makes any sense to assign a fixed value to each piece. Having said this, you
>must do whatever works for you, as long as you start with your eyes open to both
>the positive and negative aspects of your chosen approach.
>
>By the way, you should be updating things like material balance incrementally
>through the search - it's much more efficient than summing over all the pieces
>at the tips. Just add or subtract the appropriate value whenever a capture or
>promotion is made/unmade, and then at the tips you already have your material
>balance ready for inclusion in the evaluation function.
>
>Good luck with your program
>
>Roberto
I have to "second" what Roberto has to say. You will probably find
yourself indexing into arrays a lot based on which piece you are talking
about. Here is a suggestion, but of course there are myriad other
possibilities:
PAWN 1
KNIGHT 2
BISHOP 3
ROOK 4
QUEEN 5
KING 6
WHITE 16
BLACK 8
-----------------
So now a WHITE pawn becomes 16 + 1 or 17
A BLACK pawn is 8 + 1 = 9
The advantage of this over your proposal?
base_value[WHITE|PAWN] = 100
base_value[WHITE|KNIGH] = 330
...
Your array for piece values will be small, either 16 or 32 elements
depending on whether you cheat and not use the white color bit in
your index. (If the black bit is off, it's a white piece)
Now you can set up many of these lists for various purposes relating
to pieces. Do you want to have separate values for middlegame and
endgame for the pieces? It's easy now, you just have a separate array
for each.
Suppose you want to do piece square tables? It would be harder if
the cannonical knight was 300. But now:
piece_square[ ((BLACK | KNIGHT) << 6) + SQUARE ]
or more clearly: piece_square[ BLACK_KNIGHT * 64 + SQUARE ]
These operations are very fast on modern computers, they are done
at the register level and in most cases will be virtually free.
So I would say that your suggestions of 300 for knight etc, will
more than likely cause you a lot of trouble in the long run, and
you will pay the price for it.
Having said that, don't be afraid to experiment and use whatever
you feel most comfortable with. Experience will gradually teach
you what does and doesn't work very well.
About once every year or two I scrap my chess program and write
a brand new one! Each time, I try to do something significantly
different. In the process, I have learned a whole lot and have
discovered that your choice of data representation will tend to
push you along certain pathways. Right now I am trying bit boards,
something completely different in every way from what I was used
to before. This has led to the slowest, but most knowledge intensive
program I have ever written. It's slow not because of the bit
boards, but because the bit board approach ENCOURAGED the use of
lots of dynamic knowledge stuff that I would not have tried otherwise.
- Don
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.